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Preface 



Casl, the Common Algebraic Specification Language, has been designed by 
CoFI, the Common Framework Initiative for algebraic specification and de- 
velopment. Casl is an expressive language for specifying requirements and 
design for conventional software. It is algebraic in the sense that models of 
Casl specifications are algebras; the axioms can be arbitrary first-order for- 
mulas. 



This User Manual illustrates and discusses how to write Casl 
specifications. 



Casl is a major new algebraic specification language. It has been care- 
fully designed by a large group of experts as a general-purpose language for 
practical use in software development - in particular, for specifying both re- 
quirements and design. Casl includes carefully-selected features from many 
previous specification languages, as well as some novel features that allow al- 
gebraic specifications to be written much more concisely and perspicuously 
than hitherto. It may ultimately replace most of the previous languages, and 
provide a common basis for future research and development. 

Casl has already attracted widespread interest within the algebraic speci- 
fication community, and is generally regarded as a de facto standard. Various 
sublanguages of Casl are available - primarily for use in connection with 
existing tools that were developed in connection with previous languages. Ex- 
tensions of Casl provide languages oriented toward development of particular 
kinds of software (reactive, concurrent, etc.). 

Major libraries of validated Casl specifications are freely available on the 
Internet, and the specifications can be reused simply by referring to their 
names. Tools are provided to support practical use of Casl: checking the 
correctness of specifications, proving facts about them, and managing the 
formal software development process. 



VI 
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The companion Casl Reference Manual [20] provides full details of the 
Casl design, including its formal semantics. 

After briefly reviewing the background of CoFI and Casl, and the un- 
derlying concepts of algebraic specification languages, this book introduces 
the potential user to the features of Casl mainly by means of illustrative 
examples. It presents and discusses the typical ways in which the language 
concepts and constructs are expected to be used in the course of building 
system specifications. Thus, the presentation focuses on what the constructs 
and concepts of Casl are for, and how they should (and should not) be used. 
These points are made as clear as possible by referring to simple examples, and 
by discussing both the general ideas and some details of Casl specifications. 

Further chapters introduce the reader to the Casl Reference Manual, to 
some of the currently available Casl support tools, and to a couple of the Casl 
libraries of basic datatypes. A substantial case study of the practical use of 
Casl in an industrially-relevant context completes the material. Appendices 
provide a quick reference of Casl constructs, a list of the main points to bear 
in mind when using Casl, and the original informal requirements for the case 
study. 



Structure 

Part I: Background 

Chapter 1 describes the origins of Casl: how CoFI was formed in response 
to the proliferation of algebraic specification languages in the preceding two 
decades, and the aims and scope that were formulated for this international 
initiative. 

For the benefit of readers not already familiar with other algebraic specifi- 
cation languages. Chap. 2 reviews the main concepts of algebraic specification, 
explaining standard terminology regarding specification language constructs 
and models (i.e., algebras). 

Part II: Writing Casl Specifications 

Chapter 3 shows how some familiar datatypes involving total functions are 
specified in Casl, essentially as in many other algebraic specification lan- 
guages. Loose, generated, and free specifications are discussed in turn, with 
illustrative examples and advice on the use of different specification styles. 

Partial functions arise naturally. Chapter 4 explains how Casl supports 
specification of partial functions, drawing attention to where special care is 
needed compared to specifications involving only total functions. 

Subsorts and supersorts are often useful in Casl specifications. Chapter 5 
illustrates how they can be declared and defined, and that they can sometimes 
be used to avoid the need for partial functions. 
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The examples given so far make use of named and structured specifica- 
tions in a simple and natural way. Chapter 6 takes a much closer look at the 
constructs Casl provides for structuring specifications, explaining how large 
and complex specifications are easily built out of simpler ones by means of a 
small number of specification-building operations. 

Chapter 7 shows how making a specification generic (when appropriate) 
improves its reusability, allowing it to be instantiated with different argu- 
ments; compound identifiers avoid the need for explicit renaming when com- 
bining the results of different instantiations. It also introduces the constructs 
for expressing so-called views between specifications. 

While specification-building operations are useful to structure the text of 
large specifications, architectural specifications are meant for imposing struc- 
ture on implementations. Chapter 8 discusses and illustrates the role of archi- 
tectural specifications, and shows how to express them in Casl. 

Chapter 9 explains and illustrates how libraries of named specifications 
can be formed, and made available over the Internet, to encourage widespread 
reuse and evolution of specifications. Version control is of crucial importance 
here. 

Part III: Carrying On 

Chapter 10 gives a detailed overview of the foundations of Casl, which are 
established in the accompanying Casl Reference Manual. 

Tool support is vital for efficient use of formal specifications in connection 
with practical software design and development. Chapter 11 presents the main 
tools that have been implemented so far; several of them allow use of Casl 
specifications in connection with tools that were originally developed for other 
specification languages, showing how Casl provides tool interoperability. 

Chapter 12 introduces a few of the many specifications that are available 
in the Casl libraries of basic datatypes. 

Finally, Chap. 13 gives a realistic case-study of the use of Casl in practice, 
in connection with the design of software for a Steam-Boiler Control System. 
This particular example is one of the standard bench-marks for comparing 
specification frameworks [1] . 

Appendices and Indexes 

This volume is completed by three appendices: App. A provides a compact 
overview of all Casl constructs, for quick reference; App. B lists all the main 
points to bear in mind when using Casl; and App. C reproduces the informal 
requirements specification for the case study. 

The names of all the specifications given in this book are listed at the back, 
together with an index of concepts and a list of references to the literature. 
(A comprehensive annotated bibliography of publications involving Casl is 
provided in the Reference Manual.) 



VIII Preface 



An accompanying CD-ROM contains the source files for all the illustrative 
specifications, and a copy of the libraries of specifications of basic datatypes. 



Organization 



All the main points are highlighted like this. 
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The material in this book is organized in a tutorial fashion. Each main 
point is usually accompanied by an illustrative example of a complete Casl 
specification; the names of these specifications are listed (both in order of 
presentation and alphabetically) at the end of the book. Moreover, the points 
themselves are repeated (in order of presentation) in App. B. 

Readers who are familiar with previous algebraic specification languages, 
and especially those who have been following or participating in the design 
and development of Casl, may prefer to skip lightly through Chaps. 1 and 2. 
Chapter 3, however, is mandatory, since it is there that many Casl features 
needed to understand the subsequent chapters are introduced. 

In contrast. Chaps. 4 and 5 can be skipped at first reading if the reader is 
not so much interested in partial functions, resp. subsorting (with the proviso 
though that there are some references to the examples given in these chapters 
from later chapters). 

Chapters 6 and 7 present mainstream material, and until one feels com- 
fortable with all the main points and examples, it is advisable to wait with 
proceeding to Chaps. 8 and 9. 

Chapter 10 is primarily for those who will want to follow up on this book 
with a more detailed study of Casl, based on the Reference Manual. Part 
of Chap. 11 assumes familiarity with concepts introduced in Chap. 7. In 
Chap. 12, Sect. 12.1 assumes Chaps. 4 and 5, whereas Sect. 12.2 assumes 
also Chaps. 6 and 7. Finally, most of Chap. 13 can be studied after Chap. 7, 
but Sect. 13.10 requires Chap. 8. 
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Introduction 



This chapter first explains the background and aims of CoFI, the Common 
Framework Initiative for algebraic specification and development of software. 
It then gives an overview of the main features of Casl, the Common Algebraic 
Specification Language. 



1.1 CoFI 

In 1995, an open collaborative effort was initiated: to design a common frame- 
work for algebraic specification and development of software. It is referred to 
as The Common Framework Initiative, CoFI.^ 



There was an urgent need for a common framework. 
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The rationale behind this initiative was that the lack of such a common 
framework was a major hindrance for the dissemination and application of al- 
gebraic specification techniques. In particular, there was a proliferation of lan- 
guages - some differing in only quite minor ways from each other. The major 
languages included Act One/Act Two [19], ASF [6], ASL [36], Clear [15], 
Extended ML [26], Larch [25], Obj3 [24], Pluss [9], and Spectrum [14]. 
This abundance of languages was an obstacle for the adoption of algebraic 
methods for use in industrial contexts, making it difficult to exploit stan- 
dard examples, case studies and training material. A common framework, 
with widespread support at least throughout the research community, was 
urgently needed. 

^ CoFI is pronounced like ‘coffee’. 



M. Bidoit and P.D. Mosses: CASL User Manual, LNCS 2900, pp. 3—9, 2004. 
© IFIP International Federation for Information Processing 2004 
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1 Introduction 



The aim of CoFI was to base the common framework as much as possible 
on a critical selection of features that had already been explored in previous 
research and applications (see the IFIP State-of-the-Art Report on Algebraic 
Foundations of Systems Specification [3] for the background) . The collective 
experience and expertise of the CoFI participants provided a unique oppor- 
tunity to achieve this aim within a reasonably short time-span. 

The various groups working on algebraic specification frameworks had al- 
ready had ample opportunity to develop their own particular variations on 
the theme of algebraic specification [16], yet no clear ‘winner’ had emerged 
(although there were several strong contenders). 



CoFI aims at establishing a wide consensus. 
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The aim of CoFI was to design a framework incorporating just those fea- 
tures for which there would be a wide consensus regarding their appropri- 
ateness. This framework should be able to subsume many of the existing 
frameworks, and be seen as an attractive common basis for future research 
and development - with high potential for strong collaboration between the 
various groups. 

The initial overall aims of CoFI were formulated as follows: 

• A common framework for algebraic specification and software development 
is to be designed, developed, and disseminated. 

• The production of the common framework is to be a collaborative effort, 
involving a large number of experts (30-50) from many different groups 
(20-30) working on algebraic specification. 

• In the short term, the common framework is to become accepted as an ap- 
propriate basis for a significant proportion of the research and development 
in algebraic specification. 

• Specifications in the common framework are to have a uniform, user- 
friendly syntax and straightforward semantics. 

• The common framework is to be able to replace many existing algebraic 
specification frameworks. 

• The common framework is to be supported by a concise reference manual, 
user’s guide, libraries of specifications, tools, and educational materials. 

• In the longer term, the common framework is to be made attractive for 
use in industrial contexts. 

• The common framework is to be available free of charge, both to academic 
institutions and to industrial companies. It is to be protected against ap- 
propriation. 



1.1 CoFI 
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V, 



The focus of CoFI is on algebraic techniques. 



The functionality of the common framework is to allow and be useful for: 

• algebraic specification of the functional requirements of software systems, 
for some significant class of software systems; 

• formal development of design specifications from requirements specifica- 
tions, using some particular methods; 

• documenting the relation between informal statements of requirements and 
formal specifications; 

• verification of correctness of development steps from (formal) requirements 
to design specifications; 

• documenting the relation between design specifications and implementa- 
tions in software; 

• exploration of the (logical) consequences of specifications: e.g., rewriting, 
theorem-proving, prototyping; 

• reuse of parts of specifications; 

• adjustment of specifications and developments to changes in requirements; 

• providing a library of useful specification modules; and 

• providing a workbench of tools supporting the above. 



CoFI has already achieved its main aims. 
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The first major achievement of CoFI was the completion of the design of 
Casl, the Common Algebraic Specification Language. The Casl design effort 
started in September 1995. An initial design was proposed in May 1997 (with 
a language summary, abstract syntax, and formal semantics, but no concrete 
syntax) and tentatively approved by IFIP WG1.3. The report of the IFIP 
referees on the initial Casl design proposal suggested reconsideration of sev- 
eral points in the language design, and requested some improvements to the 
documents describing the design. Apart from a few details, the design was 
finalized in April 1998, and Casl version 1.0 was released in October 1998. 
IFIP WG 1.3 was asked to review the final design of Casl version 1.0.1 in 
May 2000, and subsequently approved that design in April 2001. The cur- 
rent version (1.0.2) was adopted in October 2003; it incorporates adjustments 
to some minor details of the concrete syntax and the semantics. No further 
revisions of the Casl design are anticipated. 

The Casl Reference Manual [20], published as a companion volume to 
the present book, includes a detailed yet concise (60 pages) summary of the 
Casl design; the rest of it is concerned mainly with the formal syntax and 
semantics of Casl, and with the libraries of basic datatype specifications. An 
introduction to the Reference Manual is given in Chap. 10 of this book. 
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1 Introduction 



In parallel with the design of Casl, CoFI has developed tool support for 
the use of Casl (see Chap. 11), and substantial libraries of Casl specifications 
(see Chap. 12). 

Despite the previous lack of a Casl User Manual, there is already much 
evidence that Casl is now accepted as an appropriate basis for research and 
development in algebraic specification. Reference [33] gives an overview of 
what was achieved in the period 1998-2001, and the annotated bibliography in 
the Casl Reference Manual lists a significant number of further publications 
that involve Casl. At the time of writing, it remains to be seen whether 
significant industrial take-up will follow. 

k 



CoFI is an open, voluntary initiative. 



CoFI was started by Compass (ESPRIT Basic Research WG 3264/6112, 
1989-96), in cooperation with IFIP WG 1.3 (Foundations of System Specifica- 
tion, founded 1992), on the basis of proposals made during their meetings in 
1994 (Santa Margherita Figure, Italy) and 1995 (Oslo, Norway); participation 
in CoFI was, however, never confined to members of those working groups. 
The active participants have included some 30 leading researchers in algebraic 
specification, with representatives from almost all the European groups work- 
ing in this area. (Ideally, representatives from non-European groups would 
have been involved too, but logistic difficulties prevented this.) 

Originally, CoFI had separate task groups concerning language design, 
semantics, tools, methodology, and reactive systems. There was a substantial 
amount of interaction between the task groups, which was facilitated by many 
of the CoFI participants being involved in more than one task group. The 
overall coordination of these task groups was managed by Peter Mosses from 
the start of CoFI in September 1995 until August 1998, and subsequently 
by Don Sannella. In 2003, the CoFI task groups were replaced by a looser 
coordination mechanism, with a steering committee chaired by Don Sannella. 



CoFI has received funding as an ESPRIT Working Croup, and is 
sponsored by IFIP WC 1.3. 



The European Commission provided funding for the European component 
of CoFI as ESPRIT Working Group 29432 from 1998 to 2001 [33]. The part- 
ners were the coordinating sites of the various CoFI task groups (University 
of Aarhus, University of Bremen, Ecole normale superieure de Cachan, Uni- 
versity of Genova, INRIA Lorraine, Warsaw University) with the University 
of Edinburgh as overall coordinator. The goals of the working group were to 
coordinate the completion of and disseminate the Common Framework, to 
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demonstrate its practical applicability in industrial contexts, and to establish 
the infrastructure needed for future European collaborative research in alge- 
braic techniques. Apart from this period of funding, and support for meetings 
from the Compass Working Group until its termination in 1996, CoFI has 
relied entirely on unfunded efforts by its participants. Participation in the fre- 
quent working meetings was often supported by generous subsidies from the 
local organizers. 

IFIP WG 1.3 sponsors GoFI by reviewing proposals for changes to the 
design of Gasl, and proposals for extensions of Gasl. Moreover, a considerable 
number of members of IFIP WG 1.3 have been (and, at the time of writing, 
still are) active participants of GoFI. 



New participants are welcome! 
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GoFI is an open collaboration, and new participants are always welcome. 
Gurrent information about GoFI activities is available at the main GoFI web 
site: http://www.cofi.info. The low-volume mailing list cof iOcof i . inf o 
is reserved for GoFI announcements, and discussions about GoFI activities 
generally take place on the mailing list cof i-discuss@cof i . inf o; see the 
GoFI web site for how to subscribe, and for access to the archives. 



1.2 Casl 



Casl has been designed as a general-purpose algebraic specification 
language, subsuming many existing languages. 



The primary specification language developed by GoFI is called Gasl: the 
Gommon Algebraic Specification Language. Its main features are: 

• The design of Gasl is based on a critical selection of the concepts and 
constructs found in existing algebraic specification frameworks. 

• Gasl is an expressive specification language with simple semantics and 
good pragmatics. 

• Gasl is appropriate for specifying requirements and design of conventional 
software packages. 

• Gasl is at the heart of a coherent family of languages that are obtained 
as sublanguages or extensions of Gasl. 

Gasl subsumes many previous languages for the formal specification of 
functional requirements and modular software design. Tools for Gasl are inter- 
operable, i.e., capable of being used in combination rather than in isolation. 
Gasl interfaces to existing tools extend this inter-operability (see Ghap. II). 



1 Introduction 



The intention was to base the design of Casl on a critical selection of 
concepts and constructs from existing specification languages. However, it 
was not easy to reach a consensus on a coherent language design. A great deal 
of careful consideration was given to the effect that the constructs available 
in the language would have on such aspects as the methodology and tools. A 
complete formal semantics for Casl was produced in parallel with the later 
stages of the language design, and the desire for a relatively straightforward 
semantics was one factor in the choice between various alternatives in the 
design. 

Casl represents a consolidation of past work on the design of algebraic 
specification languages. With a few minor exceptions, all its features are 
present in some form in other languages, but there is no language that comes 
close to subsuming it. Designing a language with this particular novel col- 
lection of features required solutions to a number of subtle problems in the 
interaction between features. An overview of the Casl design is presented 
in [2] , and full details are provided in the Casl Reference Manual [20] . 



Casl is at the center of a family of languages. 
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It was clear from the start that no single language could suit all purposes. 
On the one hand, sophisticated features are required to deal with specific pro- 
gramming paradigms and special applications. On the other hand, important 
methods for prototyping and reasoning about specifications only work in the 
absence of certain features: for instance, term rewriting requires specifications 
with equational or conditional equational axioms. 




Fig. 1.1. The Casl Family of Languages 



Casl is therefore at the center of a family of languages, see Fig. 1.1. 
Some tools will make use of well-delineated sublanguages of Casl, obtained by 
syntactic or semantic restrictions [29] , while extensions of Casl are generally 
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designed to support various paradigms and applications. The design of Casl 
took into account the need to define sublanguages and extensions. 



Casl itself has several major parts. 



The major parts of Casl are concerned with basic specifications, structured 
specifications, architectural specifications, and libraries of specifications. They 
have been designed to be used together: basic specifications can be used in 
structured specifications, which in turn can be used in architectural specifi- 
cations; structured and/or architectural specifications can be collected into 
libraries. However, these parts of Casl are quite independent, and may be 
understood separately, as we shall see in Part II. 



2 



Underlying Concepts 



T_, 



Casl is based on standard concepts of algebraic specification. 



This chapter reviews the main concepts of algebraic specification. It briefly 
explains and illustrates standard terminology regarding specification language 
constructs and models of specifications (i.e., algebras), and indicates the dif- 
ferences between basic, structured, and architectural specifications. 

The focus here is on concepts that are relevant to Casl, and which will 
be needed in later chapters. For comprehensive presentations of concepts and 
results concerning algebraic specification, see [3, 10, 16, 27, 34, 35, 37]; for an 
overview of the design of Casl, see [2]; and for full details of Casl, see the 
Casl Reference Manual [20]. 

The reader is assumed to be familiar with basic mathematical notions 
(sets, relations, and total and partial functions) and with the use of logical 
formulas as axioms. 



2.1 Basic Specifications 



A basic specification declares symbols, and gives axioms and 
constraints. 



A basic specification in an algebraic specification language generally con- 
sists of a set of declarations of symbols, and a set of axioms and constraints, 
which restrict the interpretations of the declared symbols. Casl allows basic 
specifications to include also items which simultaneously declare symbols and 
restrict their interpretations. 



M. Bidoit and P.D. Mosses: CASL User Manual, LNCS 2900, pp. 11-20, 2004. 
(c) IFIP International Federation for Information Processing 2004 
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2 Underlying Concepts 



V, 



The semantics of a basic specification is a signature and a class of 
models. 



The meaning or semantics of a basic specification SP generally has two 
parts: 

• a signature E, corresponding to the symbols introduced by the specifica- 
tion, and 

• a class of E -models f corresponding to those interpretations of the signa- 
ture E that satisfy the axioms and constraints of the specification. 

When a model M satisfies a specification SP, we write M ^ SP and say 
that M is a model of SP. (Formalizing this within the theory of so-called 
institutions involves categorical structure on the set of signatures and on the 
class of models, and a natural condition on the satisfaction relation. We need 
not bother with the details here - but see however the concept of a signature 
morphism in Sect. 2.2.) A specification is said to be consistent when its class 
of models is non-empty, and otherwise inconsistent. 



Casl specifications may declare sorts, subsorts, operations, and 
predicates. 



A Casl signature represents declarations of sorts, subsorts, operations, 
and predicates. The signature is called many- sorted when there are no subsort 
declarations, and otherwise subsorted; it is called algebraic when there are no 
predicate declarations. 

1-, 



Sorts are interpreted as carrier sets. 



A sort is a symbol which is interpreted as a set, called a carrier set. The 
elements of a carrier set are generally abstract representations of the data 
processed by software: numbers, characters, lists, etc. Thus a sort declared by 
a specification corresponds to a type in a programming language. Sort symbols 
are usually chosen to be strongly suggestive of their intended interpretations, 
e.g., Int for a sort to be interpreted as the set of integers. List for a set of 
lists. Casl allows also compound sort symbols, such as List[Int] for lists of 
integers. 

^ Readers who are not interested in foundational aspects may treat the word ‘class’ 
as a synonym for ‘set’. In general, the models of an algebraic specihcation in CASL 
constitute a proper class, because there is no restriction on the elements of the 
carrier sets. 
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V, 



Subsorts declarations are interpreted as embeddings. 



A sort may be declared to be a subsort or a supersort of other sorts. The 
subsort relation between two sorts could be interpreted as set inclusion. Its in- 
terpretation in Casl is however more general: it is interpreted as an embedding, 
i.e., a 1-1 function from the carrier set of the subsort to that of the supersort. 
For example, if ASCII is specified to be a subsort of ISO -Latin 1 in Casl, the 
carrier set for ASCII could be simply a subset of that for ISO-Latinl . If Char 
were to be declared as a subsort of String, however, the carrier sets for Char 
and String could be disjoint, with the embedding mapping each character to 
the corresponding single-character string. (See also the concept of overloading, 
below.) 

1-, 



Operations may be declared as total or partial. 



An operation symbol consists of the name of the operation together with its 
profile, which indicates the number and sorts of the arguments, and the result 
sort. In Casl, a declared operation symbol is interpreted as either a total or a 
partial function from the Cartesian product of the carrier sets of the argument 
sorts to the carrier set of the result sort; the subset of the argument tuples for 
which the result of a function is defined is called its domain of definition. The 
declaration indicates whether the function is total or partial.^ For example, 
integer addition would be declared as total, but integer division as partial. The 
result of applying an operation is undefined whenever any of its arguments is 
undefined (regardless of whether the operation itself is total or partial) . 

When there are no arguments, the operation is called a constant. A con- 
stant is interpreted simply as an element of the result sort. 



Predicates are different from boolean-valued operations. 



A predicate symbol consists of the name of the predicate together with its 
profile, which indicates the number and sorts of the arguments but no result 
sort: predicates are syntactically different from boolean- valued operations, 
and are used to form atomic formulas rather than terms. In Casl, a declared 
predicate symbol is interpreted as a relation on (i.e., a subset of) the Cartesian 
product of the carrier sets of the argument sorts. An application of a predicate 
is said to hold when the tuple of arguments is in the relation. For example, a 

^ A partial function might just happen to be everywhere defined, of course. 
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symbol “<’ to be interpreted as the less-than relation could be declared as a 
binary predicate on integers. 

An application of a predicate simply fails to hold when any of its arguments 
is undefined: there is no undefinedness about holding or not. This allows the 
logic to remain two-valued, and the logical connectives to have their familiar 
interpretations. 

In contrast, the result of evaluating an application of even a total boolean- 
valued operation could be true, false, or undefined: the last case arises when 
any argument of the application is undefined. Thus boolean- valued operations 
corresponding to logical connectives (conjunction, implication, etc.) have to 
take account of undefinedness, which leads to a three-valued logic. 

A further significant difference between predicates and boolean- valued op- 
erations shows up in connection with the concept of initiality, see Sect. 2.2. 
(Predicates of two- valued logic can be represented accurately by partial oper- 
ations with a single-valued result sort, holding being represented by defined- 
ness.) 



Operation symbols and predicate symbols may be overloaded. 



An operation or predicate name can be declared with different profiles in 
the same specification. This is called overloading. For example, the constant 
^ empty’ could be overloaded, being interpreted as (unrelated) elements of the 
sorts List and Set, according to the context of its use. Similarly, a predicate 
name such as ‘<’ could be overloaded on unrelated sorts such as Char and 
Int. 

In Casl, overloading is required to be compatible with embeddings between 
subsorts. For example, the sort Nat, interpreted as the set of natural numbers, 
might be a subsort of Int, interpreted as the set of all integers; then when the 
operation name ‘-I-’ and the predicate name “<’ are declared both on Nat and 
on Int, their interpretations are required to be such that it makes no difference 
whether the embedding from Nat to Int is applied to the arguments or to the 
result of the operation, and whether it is applied to the arguments of the 
predicate or not. 



Axioms are formulas of first-order logic. 



The interpretation of quantification (universal, existential, and unique- 
existential) and of the usual logical connectives (negation, conjunction, dis- 
junction, implication, and equivalence) in Casl axioms is completely standard. 
Variables in formulas range over the carrier sets of specified sorts. 
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Apart from the usual predicate applications, the atomic formulas in Casl 
axioms are equations (strong or existential), definedness assertions, and sub- 
sort membership assertions. An existential equation holds when the values of 
its terms are defined and equal; a strong equation holds moreover when the 
values of the terms are both undefined. 

Regardless of whether the values of the terms occurring in an axiom are 
defined, the axiom either holds or it does not hold in a particular model: the 
logic is two-valued, there is no “maybe” or undefinedness about the holding 
of axioms. Recall that when the value of any argument term is undefined, 
an application of a predicate never holds; similarly, definedness and subsort 
membership assertions never hold when their arguments are undefined. 



Sort generation constraints eliminate ‘junk’ from specific carrier sets. 



In general, the carrier sets of the models of a specification may contain 
‘junk’ elements, i.e., elements which cannot be obtained by any composition 
of the operations declared by the signature of the specification. 

A sort generation constraint in Casl concerns specific sorts and opera- 
tions, and is satisfied in a model when no elements of the indicated carrier 
sets are junk with respect to the indicated operations - i.e., all the elements 
of those sets can be obtained by consecutively applying those operations to 
elements of the carrier sets of the remaining sorts. For example, the carrier 
set for the sort Container might be constrained to be generated from that for 
the sort Elem by the following operations: 

• a constant ‘empty’ of sort Container, and 

• a binary operation ‘insert’ with argument sorts Elem and Container, and 
result sort Container. 

This constraint would ensure that the only elements of the Container carrier 
are those obtained by a finite number of successive applications of the insert 
operation to elements of sort Elem, starting with the empty value of sort 
Container . 



2.2 Structured Specifications 

Structured specifications are formed from basic specifications, references to 
named specifications, and instantiations of generic specifications, using various 
constructs for composing specifications. 
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The semantics of a structured specification is simply a signature and 
a class of models. 



The semantics of a structured specification is of the same form as that of 
a basic specification: a signature, together with a class of models. Thus the 
structure of a specification is not refiected in its models: it is used only to 
present the specification in a modular style. (Specification of the architecture 
of implementations is addressed in Sect. 2.3.) The symbols in the signature 
are called the exported symbols of the specification. 

The interpretation of structured specification constructs involves mappings 
between signatures 27, called signature morphisms, and corresponding map- 
pings between models M, called reducts along morphisms. In Casl, a signature 
morphism a from 27 to 27' consists of a mapping which gives: 

• for each sort of 27, a corresponding sort of 27', preserving any subsort 
relationships, and 

• for each operation or predicate symbol whose profile has sorts in 27, a 
corresponding symbol in 27' whose profile has the corresponding sorts, 
preserving any overloading between symbols whose profiles are related by 
subsorting. A partial operation may be mapped to a total operation, but 
not vice versa. 

Let M' be any 27'-model. We can define its reduct along the signature mor- 
phism a to be the 27-model M obtained as follows: each symbol of 27 is 
interpreted in M in exactly the same way as the corresponding symbol in 
27' is interpreted in M' . Conversely, given M, a model M' is said to be an 
expansion of M when the reduct of M' is M . 

Suppose that a specification SP has signature 27 and SP' has signature 27'. 
A signature morphism cr from 27 to 27' is said to be a specification morphism 
from SP to SP' when the reduct along a of each model of SP' is a model of 
SP. 

For two 27-models Mj , Mg, a (weak) homomorphism from Mj to Mg maps 
the elements of the carrier sets of Mj to the elements of the corresponding car- 
rier sets of Mg, preserving the embeddings between subsorts, the values (and 
definedness) of operations, and the holding of predicates. A homomorphism 
is an isomorphism when it has an inverse homomorphism. 

A model M is initial in a class of 27-models if there is a unique homo- 
morphism from M to each model in the class. When a class of models has 
an initial model (which need not be the case in Casl) it is unique, up to 
isomorphism. 

With reference to the above concepts of signature morphism, model reduct, 
and homomorphism, we can now proceed to explain the constructs involved 
with structured specifications. 
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V, 



A translation merely renames symbols. 



Translating a sort symbol requires translating the profiles of all opera- 
tion and predicate symbols involving that sort; translating an operation or 
predicate symbol has to respect overloading between symbols whose profiles 
are related by subsorting. The translation of sort, operation, and predicate 
names in Casl determines a signature morphism cr mapping the signature S 
of a specification SP onto a new signature S'. The models of the translation 
specification are all those models interpreting S' whose reducts along a are 
models of SP. 



Sliding symbols removes parts of models. 



Hiding a sort symbol implies hiding also all operation and predicate sym- 
bols whose profiles involve that sort; hiding an operation or predicate symbol, 
however, does not have further implications. Hiding a set of symbols that 
occur in the signature H of a specification SP to give a subsignature S' de- 
termines a signature morphism a which simply includes S' in S. The models 
of the hiding specification are the reducts of the models of SP along cr. 

For example, the operation sue might be introduced purely to facilitate 
the specification of the natural numbers, with sort Nat, constants 0 and 1 , 
and the usual arithmetic operations. Hiding sue removes the interpretation 
of sue from the models of the specification^ but leaves the carrier set for Nat 
unchanged. 



Union of speeifications identifies eommon symbols. 



The signature of a union of specifications SPi , SP2 is simply the union of 
their respective signatures S^,S2. The models of the union are those mod- 
els of the union signature whose reducts to Si and S2 along the signature 
inclusions satisfy SPi and SP2 respectively. Thus each symbol that the two 
signatures have in common has a single interpretation in any model of the 
union specification. This is known as the ‘same name, same thing’ principle. 

® The successor of a number can of course still be obtained, using addition and 1 . 
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V, 



Extension of specifications identifies common symbols too. 



The signature of the extension of a specification SP by further specification 
items (declarations, axioms, and constraints) is simply the extension of the 
signature E of SP with the symbols of the new declarations. The models of 
the extension are those models of the extended signature which satisfy the 
axioms and constraints specified by the extension and whose reducts to E 
satisfy SP . If the extension redeclares a symbol of SP, there is still only one 
occurrence of that symbol in the signature of the extension, and hence only 
one interpretation of it - again the ‘same name, same thing’ principle. 

In Casl, unions, extensions, and other kinds of structured specification 
can be formed from specification fragments that determine only signature 
extensions, not necessarily complete signatures. 



Free specifications restrict models to being free, with initiality as a 
special case. 



When a specification is freely extended by additional specification items, 
the interpretations of the additional declarations are required to satisfy the 
axioms, but nothing more: that is, properties that are not consequences of 
the axioms should not hold. In particular, the domains of definition of partial 
operations - and the sets of arguments for which predicates hold - are as 
small as possible. The carriers for the original sorts are left unchanged; any 
new carriers are no larger than is required to provide interpretations for the 
operations, without unnecessary junk elements. This restriction of the models 
is referred to as a freeness constraint. In the degenerate case where the speci- 
fication being enriched is empty, the models of the free extension are just the 
initial models. 

The difference between predicates and boolean-valued operations is par- 
ticularly apparent in free specifications: with predicates, it is only required to 
specify when they hold, since not holding is the default; with boolean- valued 
operations, however, the true and false values are treated symmetrically, and 
it is necessary to specify both cases, since neither is the default. 






Generic specifications have parameters, and have to be instantiated 
when referenced. 



A named specification may declare some parameters, the union of which 
is extended by a body, it is then called generic. The purpose of a generic 
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specification is to reuse the body in different contexts; hence a reference to a 
generic specification should instantiate it by providing, for each parameter, an 
argument specification together with a fitting morphism from the parameter 
to the argument specification. Fitting may also be achieved by use of named 
views between the parameter and argument specifications. The instantiation 
of the generic specification gives the union of the arguments, together with 
the translation of the generic specification by an expansion of the fitting mor- 
phism. This corresponds to a so-called push-out construction -- taking into 
account any explicit imports of the generic specification. 



2.3 Architectural Specifications 



T_, 



The semantics of an architectural specification reflects its modular 
structure. 



The intention with architectural specifications is primarily to impose struc- 
ture on implementations, expressing their composition from component units 
- and thereby also a decomposition of the task of developing such implemen- 
tations, from requirements specifications. This is in contrast to the structured 
specifications considered in Sect. 2.2, where the specified models have no more 
structure than do those of the basic specifications considered in Sect. 2.1. 



Architectural specifications involve the notions of persistent function 
and conservative extension. 



A function F mapping A-models to A'-models, where the signature S' 
extends S , is said to be persistent when for each A-model M , the reduct of 
F{M) to a 27-model is exactly M. 

A specification extension SP' of SP is said to be conservative when each 
model of SP can be expanded to a model of SP' . 

A persistent function mapping models of SP to models of SP' exists only 
if SP' is a conservative extension of SP. 
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2.4 Libraries of Specifications 



The semantics of a library of specifications is a mapping from the 
names of the specifications to their semantics. 



The specification of a library gives also a library name, and determines a 
version number. 



Part II 



Casl Specifications 
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Getting Started 



Simple specifications may he written in Casl essentially as in many 
other algebraic specification languages. 



The simplest kind of algebraic specification is when each specified opera- 
tion is to be interpreted as an ordinary total mathematical function: it takes 
values of particular types as arguments, and always returns a well-defined 
value. Total functions correspond to software whose execution always termi- 
nates normally. The types of values are named by simple symbols called sorts. 

In practice, a realistic software specification involves partial as well as total 
functions. However, it may well be formed from simpler specifications, some of 
which involve only total functions. This chapter explains how to express such 
simple specifications in Casl, illustrating various features of the language. 

The simple specifications discussed in this chapter can also be expressed 
in many previous specification languages; it is usually straightforward to re- 
formulate them in Casl. Readers who know other specification languages will 
probably recognize some familiar examples among the illustrations given in 
this chapter. 



Casl provides also useful abbreviations. 



The technique of algebraic specification by axioms is generally well- 
suited to expressing properties of functions. However, when functions have 
commonly-occurring mathematical properties, it can be tedious to give the 
corresponding axioms explicitly. Casl provides some useful abbreviations for 
such cases. Similarly, so-called free datatype declarations allow sorts and value 
constructors to be specified much as in functional programming languages, us- 
ing a concise and suggestive notation. 



M. Bidoit and P.D. Mosses: CASL User Manual, LNCS 2900, pp. 23-45, 2004. 
© IFIP International Federation for Information Processing 2004 
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V, 



Casl allows loose, generated and free specifications. 



The models of a loose specification include all those where the declared 
functions have the specified properties, without any restrictions on the sets 
of values corresponding to the various sorts. In models of a generated speci- 
fication, in contrast, it is required that all values can be expressed by terms 
formed from the specified constructors, i.e. unreachable values are prohibited. 
In models of free specifications, it is required that values of terms are distinct 
except when their equality follows from the specified axioms: the possibility 
of unintended coincidence between them is prohibited. 

Section 3.1 below focuses on loose specifications; Sect. 3.2 discusses the use 
of generated specifications, and Sect. 3.3 does the same for free specifications. 
Loose, generated, and free specifications are often used together in Casl: 
each style has its advantages in particular circumstances, as explained below 
in connection with the illustrative examples. 



3.1 Loose Specifications 



Casl syntax for declarations and axioms involves familiar notation, 
and is mostly self-explanatory. 


L 


[ 





spec Strict _Partial_Order = 

%% Let’s start with a simple example ! 
sort Elem 

pred __ < : Elem x Elem %% pred abbreviates predicate 

Vz, y, z : Elem 

• ~^(x < x) %(strict)% 

• X < y ^ ~^{y < x) % (asymmetric) % 

• x<yAy<z^x<z % (transitive) % 

%{ Note that there may exist x, y such that 

neither x < y nor y < x. }% 

end 

The above (basic) specification, named Strict _Partial_Order, intro- 
duces a sort Elem and a binary infix predicate symbol ‘<’. In the declaration 
of a predicate symbol, argument sorts are separated by the sign ‘ x ’, which can 
be input directly as such in ISO Latin-1 or as in ASCII. Note that Casl 
allows so-called mixfix notation, i.e., the specifier is free to indicate, using 
(pairs of underscores) as place-holders, how to place arguments when building 
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terms (single underscores are treated as letters in identifiers).^ Using mixfix 
notation generally allows the use of familiar mathematical and programming 
notations, which contributes substantially to the readability of specifications. 

The interpretation of the binary predicate symbol ‘<’ is then constrained 
by three axioms. A set of axioms is generally presented as a ‘bulleted’ list 
of formulas, preceded by the universally quantified declaration of the relevant 
variables, together with their respective sorts, as shown in the above example. 
In Casl, axioms are written in first-order logic with equality, using quantifiers 
and the usual logical connectives. The universal quantification preceding a list 
of axioms applies to the entire list. Axioms can be annotated by labels written 
%(. . . )%, which is convenient for proper reference in explanations or by tools. 

Note that ‘V’ is input as ‘forall’, and that ‘ ’ is input as or The 

usual logical connectives ‘=^’, ‘A’, ‘V’, and are input as ‘=>’, ‘<=>’, 

‘/\’, ‘\/’, and ‘not’, respectively; ‘~i’ can also be input directly as an ISO 
Latin-1 character. The existential quantifier ‘3’ is input as ‘exists’, and ‘3!’ 
is input as ‘exists ! ’. 

It is advisable to comment as appropriate the various elements introduced 
in a specification. The syntax for end-of-line and grouped multi-line comments 
is illustrated in the above example. The ‘end’ keyword ending a specification 
is optional. 

The above Strict _Partial_Order specification is loose in the sense that 
it has many (non-isomorphic) models, among which models where ‘<’ is in- 



terpreted by a total ordering relation and models where it is interpreted by 
partial one. 


a 


Specifications can easily be extended by new declarations and axioms. 


L 


[ 





spec Total_Order = 

Strict _Partial_Order 

then Vz, y : Elem • x < yN y < xV x = y %(total)% 

end 

Extensions, introduced by the keyword ‘then’, may specify new symbols, 
possibly constrained by some axioms, or merely require further properties of 
old ones, as in the above Total_Order example, or more generally do both 
at the same time. In Total_Order, we further constrain the interpretation 
of the predicate symbol ‘<’ by requiring it to be a total ordering relation. 

All symbols introduced in a specification are by default exported by it and 
visible in its extensions. This is for instance the case here for the sort Eltm and 

^ Mixfix notation is so-called because it generalizes infix, prefix, and postfix nota- 
tion to allow arbitrary mixing of argument positions and identifier tokens. 
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the predicate symbol which are introduced in Strict_Partial_Order, 
exported by it, and therefore available in Total_Order.^ 



In simple cases, an operation (or a predicate) symbol may he declared 
and its intended interpretation defined at the same time. 



spec Total_Order_With_MinMax = 

Total_Order 

then ops min{x, y : Elem) : Elem = x when x < y else y, 

max{x, y : Elem) : Elem = y when min{x, y) = x else x 

end 

Total_Order_With_MinMax extends Total_Order by introducing 
two binary operation symbols min and max, for which a functional notation 
is to be used, so no place-holders are given. The intended interpretation of 
the symbol min is defined simultaneously with its declaration, and the same 
is done for max. For instance: 

op min{x, y : Elem) : Elem = x when x < y else y 

abbreviates: 

op min : Elem X Elem —>■ Elem 

Vx, y : Elem • min{x, y) = x when x < y else y 

(and similarly for max). As for predicate symbol declarations, in an operation 
symbol declaration, the argument sorts are separated by the sign ‘x’; the 
result sort is preceded by which is input as 

The . . when . . . else . . .’ construct used above is itself an abbreviation, 
and: 

min{x, y) = X when x < y else y 
abbreviates: 

(2; < y => min{x, y) = x) A {~'{x < y) min{x, y) = y) 

In Case specifications, visibility is linear, i.e., any symbol must be declared 
before being used. In the above example, min should be declared before being 
used to define max. 

Linear visibility does not imply, however, that a fixed scheme is to be 
used when writing specifications: the specifier is free to present the required 
declarations and axioms in any order, as long as the linear visibility rule is re- 
spected. For instance, one may prefer to declare first all sorts and all operation 

^ See Chap. 6 for constructs allowing the explicit restriction of the set of symbols 
exported by a specification. 
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or predicate symbols needed, and then specify their properties by the relevant 
axioms. Or, in contrast, one may prefer to have each operation or predicate 
symbol declaration immediately followed by the axioms constraining its inter- 
pretations. Both styles are equally fine, and can even be mixed if desired. This 
flexibility is illustrated in the following variant of the Total_Order_With_ 
MinMax specification, where for explanatory purposes we refrain from using 
the useful abbreviations explained above. 

spec Variant_Of_Total_Order_With_MinMax = 

Total_Order 
then vars x,y \ Elem 

op min : Elem X Elem — > Elem 

• X < y ^ min{x, y) = x 

• ~^(x < y) ^ min{x, y) = y 
op max : Elem x Elem Elem 

• X < y ^ max{x, y) = y 

• ~^(x < y) ^ max(x, y) = x 

end 

Note that in order to avoid the tedious repetition of the declaration of the 
variables x and y for each list of axioms, we have used here a global variable 
declaration which introduces x and y for the rest of the specification. Variable 
declarations are of course not exported across specification extensions: the 
variables x and y declared in Variant_Of_Total_Order_With_MinMax 



are not visible in any of its extensions. 




Symbols may be conveniently displayed as usual mathematical 
symbols by means of %display annotations. 


L 


[ 





%display %LATEX _ < 



spec Partial_Order = 

Strict _Partial_Order 

then pred __ < __{x, y : Elem) ^ {x < y V x = y) 

end 

The above example relies on a Redisplay annotation: while, for obvious 
reasons, the specification text should be input using the ISO Latin-1 char- 
acter set, it is often convenient to display some symbols differently, e.g., as 
mathematical symbols. This is the case here where the ‘<=’ predicate symbol 
is more conveniently displayed as ‘<’. Display annotations, as any other Case 
annotations, are auxiliary parts of a specification, for use by tools, and do not 
affect the semantics of the specification.^ 

® Display annotations should be provided at the beginning of a library, and are 
explained in more detail in Chap. 9. 
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In the above example, we have again used the facility of simultaneously 
declaring and defining a symbol (here, the predicate symbol ‘<’) in order to 



obtain a more concise specification. 


L 


The %implies annotation is used to indicate that some axioms are 
supposedly redundant, being consequences of others. 


[ 





spec Partial_Order_1 = 

Partial_Order 

then %implies 

Vz, ?/, z : Elem • x<y/\y<z^x<z % (transitive) % 

end 

The %implies annotation above is used to emphasize that the transitivity 
of ‘<’ should follow from the other axioms, or, in other words, that the model 
class of Partial_Order_1 is exactly the same as the model class of Partial. 
Order. The %implies annotation applies to the whole of the specification 
extension where it occurs (which happens here to introduce a single axiom) . 

Note however that an annotation does not affect the semantics of a spec- 
ification, hence removing the %implies annotation does not change the class 
of models of the above specification. The sole aim of an %implies annotation 
is to stress the specifier’s intentions, and it will also help readers confirm their 
understanding. Some tools may of course use such annotations to generate 
corresponding proof obligations. For instance, here, the proof obligation is: 

Partial.Order 1= Vz, ?/, z : Elem • x<yAy<z^x<z 

Discharging these proof obligations increases the trustworthiness of a specifi- 
cation. 

To fully understand that an %implies annotation has no effect on the 
semantics, the best is to consider an example where the corresponding proof 
obligation cannot be discharged, as shown below. 

spec ImplieS-DoesJMotJIold = 

Partial.Order 

then %implies 

Vx, y : Elem • x<y\/y<x\/x = y %(total)% 

end 

Since the loose specification Partial.Order has models where '<’ is in- 
terpreted by a partial ordering relation, the proof obligation corresponding 
to the above %implies annotation cannot be discharged. However, since an- 
notations have no impact on the semantics, the specification Implies J3oes_ 
Not JdOLD is well-formed and just constrains the interpretation of ‘<’ to be a 
total ordering relation. The fact that the proof obligation cannot be discharged 
merely points out a potential mistake in the specification. 
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Attributes may be used to abbreviate axioms for associativity, 
commutativity, idempotence, and unit properties. 



spec Monoid = 
sort Monoid 
ops 1 : Monoid] 

Monoid x Monoid Monoid, assoc, unit 1 

end 

The above example introduces a constant symbol 1 of sort Monoid, then a 
binary operation symbol which is asserted to be associative and to have 1 
as unit element. (Note that there is no sign before the sort when declaring 
a constant.) The assoc attribute abbreviates, as expected, the following axiom: 

Vz, y, z : Monoid • (x * y) * z = x * (y * z) 

The ^unit 1’ attribute abbreviates: 

\/x : Monoid • (x*1=x)A(1*x = x) 

Note that to make the use of ‘ unit 1 ’ legal, it is necessary to have previously 
declared the constant 1 , to respect the linear visibility rule. 

Other available attributes are comm, which abbreviates the obvious axiom 
stating that a binary operation is commutative, and idem, which can be used 
to assert the idempotence of a binary operation / (i.e., that f{x, x) = x). 

Asserting to be associative using the attribute assoc makes the term 
x*y*z well-formed (assuming x,y,z of the right sort), while otherwise 
grouping parentheses would be required. Moreover, it is expected that some 
tools (e.g., systems based on rewriting) may make special use of the assoc 
attribute, so it is generally advisable to use this attribute instead of stating 
the same property by an axiom (the same applies to the other attributes). 

k 



Genericity of specifications can be made explicit using parameters. 



spec GeneriC-Monoid [sort Elern] = 
sort Monoid 

ops inj : Elem Monoid] 

1 : Monoid] 

Monoid x Monoid — > Monoid, assoc, unit 1 
Vz, y : Elem • inj(x) = inj{y) ^ x = y 



end 
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The above example describes monoids built over arbitrary elements (of sort 
Elem). The intention here is to reuse the specification Generic_Monoid to 
derive from it specifications of monoids built over, say, characters, symbols, 
etc. In such cases, it is appropriate to emphasize the intended genericity of 
the specification by making explicit, in a distinguished parameter part (which 
is here [sort Elem]), the piece of specification that is intended to vary in 
the derived specifications. In these, it will then be possible to instantiate the 
parameter part as desired in order to specialize the specification as appropriate 
(to obtain, e.g., a specification of monoids built over characters). A named 
specification with one or more parameter(s) is called generic. 

The body of the generic specification GenericJvIonoid is an extension 
of what is specified in the parameter part. Hence an alternative to the above 
generic specification GenericJVIonoid is the following, less elegant, non- 
generic specification (which cannot be specialized by instantiation): 

spec Non_Generic_Monoid = 
sort Elem 
then sort Monoid 

ops inj : Elem —f Monoid] 

1 : Monoid] 

Monoid x Monoid Monoid, assoc, unit 1 
Vz, y : Elem • inj{x) = inj{y) ^ x = y 

end 

A generic specification may have more than one parameter, and parame- 
ters can be arbitrary specifications, named or not. When reused by reference to 
its name, a generic specification must be instantiated. Generic specifications 
and how to instantiate them are discussed in detail later in Chap. 7. Using 
generic specifications when appropriate improves the reusability of specifica- 
tion definitions. 



References to generic specifications always instantiate the 
parameters. 



spec Generic_Gommutative_Monoid [sort Elem] = 

GeneriC-Monoid [sort Elem] 
then Vx, y : Monoid • x * y = y * x 

end 

The above (generic) specification Generic_Gommutative_Monoid is de- 
fined as an extension of Generic_Monoid, which should therefore be in- 
stantiated, as explained above. Instantiating a generic specification is done 
by providing an argument specification that ‘fits’ the parameter part of the 
generic specification to be instantiated. 



3.1 Loose Specifications 
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It is however quite frequent that the instantiation is ‘trivial’, i.e., the ar- 
gument specification is identical to the parameter one. This is the case for the 
above example, where the generic specification Generic_Monoid is instanti- 
ated by providing the same argument specification ‘sort Elem' as the original 
parameter. 

spec Generic_Commutative_Monoid_ 1 [sort Elem] = 
GeneriC-Monoid [sort Elem] 
then op Monoid x Monoid Monoid, comm 

end 

Generic_Gommutative_Monoid_1 is an alternative version of the for- 
mer specification where, instead of requiring explicitly with an axiom the 
commutativity of the operation we require it using the attribute comm. 
As explained before, it is in general better to describe such requirements using 
attributes rather than explicit axioms, since it is expected that some tools will 
rely on these attributes for specialized algorithms (e.g., AC term rewriting). 

This example illustrates also an important feature of Case, the ‘same 
name, same thing’ principle. The operation symbol is indeed declared 
twice, with the same profile, first in Generic_Monoid and then again in 
Generic_Commutative_Monoid_1 (the second declaration being enriched 
by the attribute comm). This is perfectly fine and defines only one binary 
operation symbol with the corresponding profile, according to the ‘same 
name, same thing’ principle. This principle applies to sorts, as well as to 
operation and predicate symbols. It applies both to symbols defined locally 
and to symbols imported from an extended specification, as it is the case here 
for ‘*’. Of course, it does not apply between separate named specifications, i.e., 
the same symbol may be used in different named specifications with entirely 
different interpretations. 

Note that for operation and predicate symbols, the ‘same name, same 
thing’ principle is a little more subtle than for sorts: the ‘name’ of an operation 
(or of a predicate) includes its profile of argument and result sorts, so two 
operations defined with the same symbol but with different profiles do not have 
the same ‘name’, the symbol is just overloaded. When an overloaded symbol 
is used, the intended profile is to be determined by the context (e.g., the sorts 
of the arguments to which the symbol is applied). Explicit disambiguation 
can be used when needed, by specifying the profile (or result sort) in an 
application.® Note that overloaded constants are allowed in Case (e.g., empty 
may be declared to be a constant of various sorts of collections) . 



^ See also the discussion of overloading in presence of subsorts in Chap. 5, p. 61. 

® For instance, depending on the context, the term tl * t2 can be disambiguated by 
writing {op * : Monoid x Monoid — > Monoid){tl , t2), or just {tl : Monoid) * {t2 : 
Monoid), or even {tl * t2) : Monoid. 
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V, 



Datatype declarations may be used to abbreviate declarations of sorts 
and constructors. 



spec Container [sort Elem] = 

type Container ::= empty \ insert{Elem] Container) 
pred _jisjin__ : Elem x Container 
Ve, e' : Elem; C : Container 

• ^(e is -in empty) 

• e is-in insert{e' , C) (e = e' V e is-in C) 

end 

Specifications of ‘datatypes’ with constructors are frequently needed. Case 
provides special constructs for datatype declarations to abbreviate the corre- 
sponding rather tedious declarations. For instance, the above datatype decla- 
ration: 



type Container ::= empty \ insert{Elem', Container) 

abbreviates: 

sort Container 

ops empty : Container] 

insert : Elem X Container — > Container 

A datatype declaration looks like a context-free grammar in a variant 
of BNF. It declares the symbols on the left of as sorts, and for each 
alternative on the right it declares a constructor. 

A datatype declaration as the one above is loose since it does not imply 
any constraint on the values of the declared sorts: there may be some values 
of sort Container that are not built by any of the declared constructors, and 
the same value may be built by different applications of the constructors to 
some arguments. 



Datatype declarations may also be specified as generated (see Sect. 3.2) or 
free (see Sect. 3.3). Moreover, selectors, which are usually partial operations, 
may be specified for each component (see Chap. 4). 



Loose datatype declarations are appropriate when further 
constructors may be added in extensions. 


L 


[ 





spec MarkinG-Container [sort Elem] = 

Container [sort Elem] 

then type Container ::= mark -insert {Elem] Container) 



3.2 Generated Specifications 
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pred -marked -in— : Elem x Container 

Ve, e' : Elem; C : Container 

• e is-in mark -insert {e' ^ G) (e = e' V e is-in C) 

• ~^{e is-marked-in empty) 

• e is-marked-in insert{e' , C) e is-marked-in C 

• e is-marked-in mark -insert {e' ^ G) (e = e' V e is-marked-in C) 

end 

The above specification extends Container (trivially instantiated) by 
introducing another constructor mark-insert for the sort Container (hence, 
values added to a container may now be ‘marked’ or not). Note that we 
heavily rely on the ‘same name, same thing’ principle here, since it ensures 
that the sort Container introduced by the datatype declaration of Container 
and the sort Container introduced by the datatype declaration of Marking. 
Container are the same sort, which implies that the combination of both 
datatype declarations is equivalent to: 

type Container ::= empty \ insert{Elem] Container) 

I mark -insert {Elem] Container) 

Note that since ‘new’ values may be constructed by mark-insert, it is 
necessary to extend the specification of the predicate symbol is -in by an 
extra axiom taking care of the newly introduced constructor. 



3.2 Generated Specifications 



Sorts may be specified as generated by their constructors. 



spec Generated.Container [sort Elem] = 

generated type Container ::= empty \ insert{Elem] Container) 
pred -is-in— : Elem x Container 
Ve, e' : Elem; C : Container 

• ^(e is -in empty) 

• e is-in insert{e' , G) <G> (e = e' V e is-in C) 

end 

When a datatype is declared as generated, as in the above example, the 
corresponding sort is constrained to be generated by the declared constructors, 
which means that any value of this sort is built by application of construc- 
tors. This constraint is sometimes referred to as the ‘no junk’ principle. For 
instance, in the above example, having declared the datatype Container to be 
generated entails that in any model of Generated.Container, any value of 
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sort Container is denotable by a term built with empty, insert, and variables 
of sort Elem only. 

As a consequence, properties of values of sort Container can be proved 
by induction on the declared constructors. A major benefit of generated 
datatypes is indeed that induction on the declared constructors is a sound 
proof principle. 



The construct ‘generated type . . . ’ used above is just an abbreviation 
for ‘generated { type ... }’, and ‘generated’ can be used around arbitrary 
signature declarations, enclosed in ‘{’ and ‘}’. 



Cenerated specifieations are in general loose. 



spec Generated_Container_Merge [sort Elem] = 
Generated_Container [sort Elem] 
then op .jmerge— : Container x Container — > Container 
Ve : Elem', C, C : Container 

• e is jin (C merge C) (e is jin G V e is jin C') 

end 

A generated specification is in general loose. For instance. Generated. 
Gontainer is loose since, although all values of sort Container are specified to 
be generated by empty and insert, the behavior of the insert constructor is still 
loosely specified (nothing is said about the case where an element is inserted 
into a container which already contains this element). Hence Generated. 
Gontainer admits several non-isomorphic models. 

Generated.Gontainer.Merge is as loose as Generated.Gontainer 
with respect to insert, and in addition, the newly introduced operation symbol 
merge is also loosely specified: nothing is said about what happens when 
merging two containers which share some elements. 

It is important to understand that looseness of a specification is not a prob- 
lem, but on the contrary avoids unnecessary overspecification. In particular, 
loose specifications are in general well-suited to capturing requirements. 

The fact that merge is loosely specified does not mean that it can pro- 
duce new values of the sort Container. On the contrary, since this sort has 
been specified as being generated by empty and insert, it follows that any 
value denotable by a term of the form merge{. ..,...) can also be denoted by 
a term built with empty and insert (and no merge). Hence, for the specifi- 
cation Generated.Gontainer.Merge, proofs by induction on Container 
only need to consider empty and insert, and not merge, as was the case for 
Generated.Gontainer. 



3.2 Generated Specifications 
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Generated speeifieations need not be loose. 



spec Generated_Set [sort Elem] = 

generated type Set ::= empty \ insert{Elem; Set) 

pred _JsJn__ : Elem x Set 

ops {— }(e : Elem) : Set = insert{e, empty); 

__ U __ : Set X Set — > Set; 

remove : Elem x Set —>■ Set 

Ve, e' : Elem; S, S' : Set 

• ~^(e is -in empty) 

• e is-in insert{e' , 6') <G> (e = e' V e is-in S) 

• S = S' 4^ (Vx : Elem • x is-in S 4^ x is-in S') %(equal^ets)% 

• e is-in {S U S') (e is-in 5 V e is-in S') 

• e is-in remove{e' , S) <G> (~'(e = e') A e is-in S) 

then %implies 

Ve, e' : Elem; S : Set 

• insert{e,insert{e, S)) = insert{e, S) 

• insert{e, insert{e' , S)) = insert{e', insert{e, S)) 

generated type Set ::= empty \ {—}{Elem) \ __U —{Set; Set) 
op __U : Set X Set — > Set, assoc, comm, idem, unit empty 

end 

Although generated specifications are in general loose, they need not be so, 
as illustrated by the above Generated_Set specification, where the axiom 
%(equal_sets)%, combined with the axioms defining is-in, fully constrains (up 
to isomorphism) the interpretations of the sort Set and of the constructors 
empty and insert, once an interpretation for the sort Elem is chosen. 

Note also that this example displays the power of the annotation %implies. 
Remember that this annotation applies to the whole of the specification ex- 
tension where it occurs, so here it applies not only to the two explicit axioms 
about insert, but also to the properties corresponding to the attributes of ‘U’ 
as well as to the generatedness constraint. Hence, the %implies annotation is 
used here not only to stress that the usual properties of insert are expected to 
follow from the preceding declarations and axioms, but also that an alterna- 
tive induction scheme, based on empty, {__} and __U can be used for sets. 
Moreover, it asserts that __ U __ is expected to be associative, commutative, 
idempotent (i.e., 5 U 5 = S), and to have empty as unit. Note again that this 
%implies part heavily relies on the ‘same name, same meaning’ principle. 
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V, 



Generated types may need to be declared together. 



The following specification fragment illustrates what may go wrong, 
sort Node 

generated type Tree ::= mktree{Node] Forest) 
generated type Forest ::= empty \ add{Tree; Forest) 

The above is incorrect, due to the linear visibility rule. This can easily 
be fixed by replacing ‘sort Node’ by ‘sorts Node, Tree, Forest’. Even when 
corrected, the above is wrong, since the corresponding semantics is not what a 
naive reader may expect. One may expect that only models where the carrier 
sets of the sorts Tree and Forest are generated by mktree, empty and add are 
acceptable, but more models satisfy the above two separate sort generatedness 
constraints. For instance, a model with both a junk tree jt and a junk forest 
jf fulfills the above declarations (assuming that the interpretations of mktree 
and add on jt and jf in this model are such that jt = mktree {n, jf) for any 
node n and that jf = add{jt,jf) ). Hence, one must write instead: 

sort Node 

generated types Tree ::= mktree{Node; Forest); 

Forest ::= empty \ add{Tree; Forest) 

Here, the mutually recursive datatypes Tree and Forest are correctly de- 
fined simultaneously within the same generated types construct, and the 
resulting semantics is the expected one (without junk values for trees and 
forests). Note that therefore, the linear visibility rule is not applicable within 
a generated types construct (to allow such mutually recursive definitions), 
but that this is the only exception to the linear visibility principle. Only 
mutually recursive generated datatypes need to be declared together; in sim- 
pler cases, it makes no difference to have a sequence of successive generated 
datatype declarations or just one introducing all the desired datatypes.® 



3.3 Free Specifications 



Free specifications provide initial semantics and avoid the need for 
explicit negation. 



spec Natural = free type Nat :■.= 0 \ suc(Nat) 



The same explanations apply to free datatypes, introduced in the next subsection. 



3.3 Free Specifications 
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A free datatype declaration corresponds to the so-called ‘no junk, no 
confusion’ principle: there are no other values of sort Nat than those denoted 
by the constructor terms built with 0 and sue, and all distinct constructor 
terms denote different values. 

Hence, a free datatype declaration such as the one above has exactly the 
same effect as the corresponding generated datatype declaration, together 
with axioms stating that sue is injective, and that 0 cannot be the successor 
of a natural number. An alternative to the above ‘free type Nat ::= 0 \ 
suc(Nat)’ is therefore: 

generated type Nat ::= 0 \ suc(Nat) 

Vz, y : Nat • suc(x) = suc(y) x = y 
Vz : Nat • -^{0 = suc(x)) 



V, 



Free datatype declarations are particularly convenient for defining 
enumerated datatypes. 



spec Color = 

free type RGB ::= Red \ Green \ Blue 

free type GMYK ::= Gy an \ Magenta \ Yellow \ Black 

end 



Using ‘free’ instead of ‘generated’ for defining enumerated datatypes 
saves the writing of many explicit distinctness assertions (for instance, here, 
-^{Red = Green), ^{Red = Blue), . . .). 



Free specifications can also be used when the constructors are related 
by some axioms. 


L 


[ 





spec Integer = 

free { type Int ::= 0 \ suc(Int) \ pre{Int) 

\/x : Int • suc{pre{x)) = x 
• pre(suc(x)) = x } 

end 

When some relations are to be imposed between the constructors (as is the 
case here for sue and pre which are inverses of each other), a free datatype 
declaration cannot be used, since the contradiction between the ‘no confu- 
sion’ principle and the axioms imposed on the constructors would lead to an 
inconsistent specification. Instead, one should impose a ‘freeness constraint’ 
around the datatype declaration followed by the required axioms. A freeness 
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constraint, expressed by the keyword free, can be imposed around any spec- 
ification. 

In the case of the above Integer specification, the freeness constraint 
imposes that the semantics of the specification is the class of all algebras iso- 
morphic to the quotient of the constructor terms by (the minimal congruence 
induced by) the given axioms. This is exactly the desired semantics. More gen- 
erally, a freeness constraint around a specification indicates its initial model, 
which may not exist, of course. It is however well-known that initial models of 
basic specifications with axioms restricted to Horn clauses (of which equations 
as in Integer are a special case) always exist. ^ Remember also that equality 
holds minimally in initial models of equational specifications. 



Predicates hold minimally in models of free specifications. 



spec Natural_Order = 

Natural 

then free { pred Nat x Nat 

Vx, y : Nat 

• 0 < suc(x) 

• X < y ^ suc(x) < suc(y) } 

end 

A freeness constraint imposed around a predicate declaration followed by 
some defining axioms has the effect that the predicate only holds when this 
follows from the given axioms, and does not hold otherwise. For instance, in 
the above example, it is not necessary to explicitly state that ‘^(0 < 0)’, 
since this will follow from the imposed freeness constraint. Hence, in such 
cases a freeness constraint has exactly the same effect as the so-called ^nega- 
tion as failure’ or ^closed world assumption’ principles in logic programming. 
More generally, it is often convenient to define a predicate within a freeness 
constraint, since by doing so, one has to specify the ‘positive’ cases only. 



Operations and predicates may he safely defined by induction on the 
constructors of a free datatype declaration. 



spec Natural_Arithmetic = 

Natural_Order 

^ Strictly speaking, existence of initial models depends on a further requirement: 
namely the existence of a ground term for each sort. This ensures that the term- 
algebra has non-empty carriers and hence is a Casl model. 



3.3 Free Specifications 
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then ops 1 : Nat = suc{0); 

Nat X Nat Nat, assoc, comm, unit 0; 

: Nat X Nat Nat, assoc, comm, unit 1 

Vx, y : Nat 

• X + suc{y) = suc{x + y) 

• X * 0 = 0 

• X * suc{y) = {x * y) + X 

end 

To define some operation on a free datatype, it is generally recommended 
to make a case distinction with respect to the various constructors defined. 
This is illustrated by the above definitions of '+’ and (although for the 
‘+’ operation, the case for the constructor 0 is already taken care of by the 
attribute ‘unit 0’).® 



More care may be needed when defining operations or predicates on 
free datatypes when there are axioms relating the constructors. 



spec Integer_Arithmetic = 



Integer 






then ops 1 


Int = sue 


{oy, 


__-b - 


Int X Int 


— > Int, assoc, comm 


__ — __ 


Int X Int 


Int] 


__ * __ 


Int X Int 


Int, assoc, comm 



Vx, y : Int 

• X + suc{y) = suc{x + y) 

• X + pre{y) = pre{x + y) 

• X — 0 = X 

• X — suc(y) = pre(x — y) 

• X — pre{y) = suc(x — y) 

• X * 0 = 0 

• X * suc{y) = {x * y) + X 

• X * pre{y) = {x * y) — x 

end 



unit O', 
unit 1 



While a case distinction with respect to the constructors of a free datatype 
is harmless, this may not be the case for a datatype defined within a freeness 
constraint, since, due to the axioms relating the constructors to each other, 
some cases may overlap. This does not mean, however, that one cannot use 
the case distinction, but just that more attention should be paid than for a 
free datatype - since one needs to ensure that the definitions lead to the same 



In specification libraries, ordinary decimal notation for natural numbers can be 
provided by use of so-called literal syntax annotations, see Chap. 9. 
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results for overlapping cases. For instance, in the above example no problem 
arises. But one should be more careful with the next one, since a negative 
integer can be of the form suc(x), hence asserting, e.g., 0 < suc(x), would of 
course be wrong. 

spec Integer_Arithmetic_Order = 

Integer_Arithmetic 

then preds Int x Int 

Vz, y : Int 
• 0 <0 

• ~^{0 < pre{0)) 

• 0 < X ^ 0 < suc(x) 

• ^(0 < x) ^ ^(0 < pre(x)) 

• suc(x) < y ^ X < pre{y) 

• pre{x) < y ^ X < suc{y) 

• X > y y < X 

• x<y<^{x<y/\ ~^{x = y)) 

• X > y ^ y < X 

end 



Generic specifications often involve free extensions of (loose) 
parameters. 



spec List [sort Elem] = free type List ::= empty \ cons{Elem; List) 

The parameter of a generic specification should be loose to cope with the 
various expected instantiations. On the other hand, it is a frequent situation 
that the body of the generic specification should have a free, initial interpre- 
tation. This is illustrated by the above example, where we want to combine a 
loose interpretation for the sort Elem with a free interpretation for lists. The 
following example is similar in spirit. 

spec Set [sort Elem] = 

free { type Set ::= empty \ insert{Elem] Set) 
pred _jisjin__ : Elem x Set 
Ve, e' : Elem] S : Set 

• insert{e, insert{e, S)) = insert{e, S) 

• insert(e, insert(e', S)) = insert(e', insert(e, S)) 

• ^(e is-in empty) 

• e is-in insert{e, S) 

• e is-in insert{e' , S) if e isJn S } 



end 



3.3 Free Specifications 
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As for the List example, we want to have a loose interpretation for the 
sort Elem and a free interpretation for sets. Since some axioms are required to 
hold for the Set constructors empty and insert, we cannot use a free datatype 
declaration, hence we use a freeness constraint. 

Note that since, as already explained, predicates hold minimally in models 
of free specifications, it would have been enough, in the above example, to 
define the predicate is-in by the sole axiom e is-in insert{e, S).^ However, 
doing so would have decreased the comprehensibility of the specification and 
this is the reason why we have preferred a more verbose axiomatization of the 
predicate is jin. 

Note also the use of the keyword ‘if’ to write an implication in the reverse 
order: 

e isJn insert{e',S) if e is-in S 
is equivalent to: 

e is-in 5 => e isJn insert{e',S) 

The following example specifies the transitive closure of an arbitrary binary 
relation R on some sort Elem (both provided by the parameter). 

spec Transitive_Closure [sort Elem pred : Elem x Elem] = 
free { pred : Elem x Elem 

\/x, y, z : Elem 

• X R y ^ X R~^y 

• X R~^y A y x } 

In the above example, it is crucial that predicates hold minimally in models 
of free specifications, since this property ensures that what we define as ‘i?+’ 
is actually the smallest transitive relation including R. Without requiring the 
freeness constraint, one would allow arbitrary transitive relations containing 
R (and these undesired relations cannot be eliminated merely by specifying 
further first-order axioms). 



Loose extensions of free specifications can avoid overspecification. 



spec Natural_With_Bound = 

Natural_Arithmetic 
then op max size : Nat 
• 0 < max size 

end 

® If an element e belongs to a set S' , then this set S' can always be denoted by 
a constructor term of the form insert {e, S), due to the axioms constraining the 
constructor insert. 
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The above example shows another benefit of mixing loose and initial se- 
mantics. Assume that at this stage we want to introduce some bound, of sort 
Nat, without fixing its value yet (this value is likely to be fixed later in some 
refinement, and all that we need for now is the existence of some bound). This 
is provided by the above specification Natural_With JBound, where we mix 
an initial interpretation for the sort Nat (defined using a free datatype dec- 
laration in Natural) and a loose interpretation for the constant maxsize. 
Each model of Natural_With_Bound will provide a fixed interpretation 
of the constant maxsize, and all these models are captured by Natural. 
With_Bound, which is in this sense loose. Using such loose extensions is in 
general appropriate to avoid unnecessary overspecification. 

spec Set.Choose [sort Elem] = 

Set [sort Elem] 
then op choose : Set —>■ Elem 

yS : Set • ^{S = empty) choose(S) isJn S 

end 

This example shows again the benefit of mixing initial and loose seman- 
tics. Here, we want to extend sets, defined using a free constraint in Set, by a 
loosely specified operation choose}^ At this stage, the only property required 
for choose is to provide some element belonging to the set to which it is ap- 
plied, and we do not want to specify more precisely which specific element is 
to be chosen. Note that each model of Set.Choose will provide a function 
implementing some specific choice strategy, and that since all these interpreta- 
tions of choose have to be functions, they are necessarily ‘deterministic’ (e.g., 
applied twice to the same set argument, they return the same result). 



Datatypes with observer operations or predicates can he specified as 
generated instead of free. 



spec Set.Generated [sort Elem] = 

generated type Set ::= empty ] insert{Elem; Set) 
pred : Elem x Set 

ye, e! : Elem; S, S' : Set 

• ~^{e is -in empty) 

• e is-in insert{e' , 5) <t4> (e = e' V e is-in S) 

• S = S' (f/x : Elem • x is-in S 4^ x is-in S') 

end 



10 



For the purpose of this example, we disregard the fact that choose should be un- 
defined on the empty set, and we just leave this case unspecihed. Partial functions 
are discussed in Chap. 4. 



3.3 Free Specifications 
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The above specification is an alternative to the specification Set (see 
p. 40). Both Set and Set .Generated define exactly the same class of 
models. The former specification relies on a freeness constraint, while Set. 
Generated relies on the observer is -in to specify when two sets are equal. 
Indeed, the last axiom of Set.Generated expresses directly that two sets 
having exactly the same elements are equal values. This axiom, together with 
the first two axioms defining is -in, will entail as well the expected proper- 
ties on the constructor insert (see Generated.Set p. 35). Note also that 
since, in Set.Generated, the predicate is-in is not defined within a free- 
ness constraint, we specify when it holds using rather than a one-way 
implication. 

While a freeness constraint may be unavoidable to define a predicate, as 
illustrated by Transitive.Glosure, the choice between relying on a free- 
ness constraint to define a datatype such as Set, or using instead a generated 
datatype declaration together with some observers to unambiguously deter- 
mine the values of interest, is largely a matter of convenience. One may argue 
that Set is more suitable for prototyping tools based on term rewriting, while 
Set.Generated is more suitable for theorem-proving tools. 



The %def annotation is useful to indicate that some operations or 
predicates are uniquely defined. 



spec Set .Union [sort Elem] = 

Set [sort Elem] 
then %def 

ops .. U.. \ Set X Set ^ Set, assoc, comm, idem, unit empty, 
remove : Elem x Set — > Set 

Ve, e' : Elem-, S , S' : Set 

• S U insert{e' , S') = insert{e', S U S') 

• remove{e, empty) = empty 

• remove{e,insert{e, S)) = remove{e, S) 

• remove{e,insert{e' , S)) = insert{e' , remove{e, S)) if ^(e = e') 

end 

The annotation %def expresses that Set .Union is a definitional extension 
of Set, i.e., that each model of Set can be uniquely extended to a model of 
Set.Union, which means that the operations introduced in Set.Union are 
uniquely defined. As with the %implies annotation, the %def annotation 
has no impact on the semantics, but a corresponding proof obligation can be 
generated, to be discharged by theorem proving tools. The %def annotation 
is especially useful to stress that the specifier’s intention is to impose a unique 
interpretation of what is defined within the scope of this annotation (once an 
interpretation for the part which is extended has been chosen). 
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3 Getting Started 



Operations can be defined by axioms involving observer operations, 
instead of inductively on constructors. 


L 


[ 





spec Set_Union_ 1 [sort Elem] = 

Set_Generated [sort Elem] 
then %def 

ops __U__ \ Set X Set ^ Set, assoc, comm, idem, unit empty, 
remove : Elem x Set — > Set 

Ve, e' : Elem] S , S' : Set 

• e is -in (S U S') (e is -in S V e is -in S') 

• e is-in remove{e' ,S) (“>(e = e') A e is-in S) 

end 

The specification Set_Union_1 is an alternative to Set_Union and de- 
fines exactly the same model class. While an inductive definition style was cho- 
sen for the operations ‘U’ and remove in Set_Union, in Set_Union_1 these 
operations are defined ‘implicitly’ by characterizing their results through the 
observer is -in. Note that this ‘observer’ style does not prevent us providing a 
unique definition of both operations, as claimed by the %def annotation. 

Similarly to the discussion on the respective merits of Set and of Set_ 
Generated, the choice between an inductive definition style and an ‘ob- 
server’ definition style is partly a matter of taste. One may argue that the 
‘observer’ definition style is more abstract in the sense that there is no hint 
to any algorithmic computation of the so-defined operations, while the induc- 
tive definition style mimics a recursive definition in a functional programming 
language. Again, the inductive definition style may be more suitable for pro- 
totyping tools based on term rewriting, while the ‘observer’ definition style 
may be more suitable for theorem-proving tools. 

k 



Sorts declared in free specifications are not necessarily generated by 
their constructors. 



spec UnNatural = 

free { type UnNat ::= 0 \ suc{UnNat) 

op UnNat x UnNat — > UnNat , 

assoc, comm, unit 0 
\/x, y : UnNat • x + suc{y) = suc{x + y) 

\/x : UnNat • 3y : UnNat • x + y = 0 } 

end 

This rather peculiar example illustrates the fact that a sort defined within 
a freeness constraint need not be generated by its constructors. In UnNat- 
ural, the specification enclosed within the free { . . . } construct specifies 



3.3 Free Specifications 
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Abelian groups with one generator suc{0), and the integers are the free such 
Abelian group. Hence, the (unique up to isomorphism) model of UnNatural 
corresponds to integers, and not to natural numbers as one may expect - just 
consider the last axiom. This example points out why in general datatypes 
defined using freeness constraints can be more difficult to understand than 
datatypes defined using generatedness constraints. However, the reader should 
be aware that the specification UnNatural uses a proper first-order formula 
with an existential quantifier in the axioms. The specification UnNatural is 
provided here for explanatory purposes only, and clearly the writing of simi- 
lar specifications should be discouraged. When only Horn clauses are used as 
axioms in a freeness constraint, then the datatype will indeed be generated 
by its constructors. 



4 



Partial Functions 



V, 



Partial functions arise naturally. 



Partial functions arise in a number of situations. Casl provides means 
for the declaration of partial functions, the specification of their domains of 
definition, and more generally the specification of system properties involving 
partial functions. The aim of this chapter is to discuss and illustrate how to 
handle partial functions in Casl specifications. 



4.1 Declaring Partial Functions 



Partial functions are declared differently from total functions. 



spec Set_Partial_Choose [sort Elem] = 
Generated_Set [sort Elem] 
then op choose : Set — >? Elem 

end 



The choose function on sets is naturally a partial function, expected to be 
undefined on the empty set. In Casl, a partial function is declared similarly 
to a total one, but for the question mark '?’ following the arrow in the profile. 
It is therefore quite easy to distinguish the functions declared to be total from 
the ones declared to be partial. 

A function declared to be partial may happen to be total in some of 
the models of the specification. For instance, the above specification Set_ 
Partial_Choose does not exclude models where the function symbol choose 
is interpreted by a total function, defined on all set values. Axioms can be 
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4 Partial Functions 



used to specify the domain of definition of a partial function, and how to do 
this is detailed later in this chapter. 



Terms containing partial functions may he undefined, i.e., they may 
fail to denote any value. 



For instance, the (value of the) term choose{empty) may be undefined.^ 
This is more natural than insisting that choose{empty) has to denote some 
arbitrary but fixed element of Elem. 

Note that variables range only over defined values, and therefore a variable 
always denotes a value, in contrast to terms containing partial functions. 






Functions, even total ones, propagate undefinedness. 



If the term choose{S) is undefined for some value of S, then the term 
insert{choose{S), S') is undefined as well for this value of S, although insert 
is a total function. 

k 



Predicates do not hold on undefined arguments. 



Casl is based on classical two-valued logic. A predicate symbol is inter- 
preted by a relation, and when the value of some argument term is undefined, 
the application of a predicate to this term does not hold. For instance, if the 
term choose{S) is undefined, then the atomic formula choosers) is jin S does 
not hold. 

k 



Equations hold when both terms are undefined. 



In Casl, equations are by default strong, which means that they hold 
not only when both sides denote equal values, but also when both sides are 
simultaneously undefined. For instance, let us consider the equation: 

insert (choose{S) , insert {choose{S) , empty)) = insert (choose{S), empty) 

^ Note that the term choose(empty) is well-formed and therefore is a ‘correct term’. 
It is its value which may be undefined. To avoid unnecessary pedantry, in the 
following we will simply write that a term is undefined to mean that its value 
is so. Obviously, a term with variables may be defined for some values of the 
variables and undefined for other values. 



4.1 Declaring Partial Functions 
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Either choose{S) is defined and then both sides are defined and denote equal 
values due to the axioms on insert, or choose{S) is undefined and then both 
sides are undefined, and the strong equation ‘holds trivially’. 

Casl provides also so-called existential equations, explained at the end of 
this chapter. 



Special care is needed in specifications involving partial functions. 



Partial functions are intrinsically more difficult to understand and specify 
than total ones. This is why special care is needed when writing the axioms 
of specifications involving partial functions. The point is that an axiom may 
imply the definedness of terms containing partial functions, and as a conse- 
quence that these functions are total, which may not be what the specifier 
intended. Here are three typical cases: 

• Asserting choose(S) is -in S as an axiom implies that choose(S) is defined, 
for any S. The point here is that since predicates applied to an undefined 
term do not hold, in any model satisfying choose(S) is-in S, the function 
choose must be total (i.e., always defined). 

• Asserting remove{choose{S) , insert{choose{S) , empty)) = empty as an ax- 
iom implies that choose (S) is defined for any S, since the term empty 
is always defined. To understand this, assume that choose is undefined 
for some set value of S; then the above equation cannot hold for this 
value, since the undefinedness of choose {S) implies the undefinedness of 
remove{choose{S) , insert{choose{S) , empty)), giving a contradiction with 
the definedness of empty. Hence, an equation between a term involving a 
partial function PF and a term involving total functions only may imply 
that the partial function PF is always defined. 

• Asserting insert{choose{S), S) = 5 as an axiom implies that choosers) is 
defined for any S, since a variable always denotes a defined value. This 
case is indeed similar to the previous one, the only difference being that 
now the right-hand side of the equation is a variable (instead of a term 
involving total functions only). 

Moreover, the ‘same name, same thing’ principle has a subtle side-effect re- 
garding partial operations: if an operation is declared both as a total operation 
and as a partial operation with the same profile (i.e., the same argument sorts 
and the same result sort) then it is interpreted as a total operation in all 
models of the specification. 
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4 Partial Functions 



4.2 Specifying Domains of Definition 



v, 



The definedness of a term can be checked or asserted. 



spec Set_Partial_Choose_ 1 [sort Elem] = 

Set_Partial_Choose [sort Elem] 
then • ^ def choose{empty) 

yS : Set • def choose{S) choose{S) isJn S 

end 

A definedness assertion, written ‘def t’, where t is a term, is a special kind 
of atomic formula: it holds if and only if the value of the term t is defined. For 
instance, in the above example, ^ def choose{empty) explicitly asserts that 
choose is undefined when applied to empty. Note that this axiom does not 
say anything about the definedness of choose applied to values other than 
empty, which means that choose may well be undefined on those values too. 
The second axiom of the above example asserts choose{S) is-in S under the 
condition def choose{S), to avoid undesired definedness induced by axioms, 
as explained in the previous section. 

Note that if the two axioms of the above example were to be replaced by: 

yS : Set • ^{S = empty) choose(S) isJn S 

then we could conclude that choose{S) is defined when S is not equal to 
empty, but nothing about the undefinedness of choose{empty) . 



The domains of definition of partial functions can be specified 
exactly. 



spec Set_Partial_Choose_ 2 [sort Elem] = 

Set_Partial_Choose [sort Elem] 
then yS : Set • def choose(S) ~^{S = empty) 

yS : Set • def choose(S) choose{S) isJn S 

end 

In the above example, the domain of definition of the partial function 
choose is exactly specified by the axiom def choose(S) 4^ ^{S = empty). 



4.2 Specifying Domains of Definition 
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V, 



Loosely specified domains of definition may be useful. 



spec Natural_With_Bound_And_Addition = 
Natural_With_Bound 
then op : Nat x Nat — >? Nat 

Mx, y : Nat 

• def{x+7y) if x + y < max size 
%{ X + y < maxsize implies both 

X < maxsize and y < maxsize }% 

• def{x+ly) => x+ly = x + y 

end 



In some cases, it is useful to loosely specify the domain of definition of a 
partial function, as illustrated in the above example for ‘+?’, which is required 
to be defined for all arguments x and y such that x + y < maxsize, but 
may well be defined on larger natural numbers as well. The point in loose 
specifications of definition domains is to avoid unnecessary constraints on the 
models of the specification. For instance, the above example does not exclude a 
model where ‘+?’ is interpreted by a total function (which would then coincide 
with ‘+’).^ 

Indeed, in some cases, specifying exactly domains of definition can be con- 
sidered as overspecification. In most specifications, however, one would expect 
an exact specification of domains of definition, even for otherwise loosely spec- 
ified functions (see, e.g., choose in Set_Partial_Choose_2). 



Domains of definition can be specified more or less explicitly. 



spec Set_Partial_Choose_3 [sort Elem] = 

Set_Partial_Choose [sort Elem] 
then • ^ def choose{empty) 

yS : Set • = empty) choose(S) isJn S 

end 

Set_Partial_Choose_ 3 specifies exactly the domain of definition of 
choose, but does this too implicitly, since some reasoning is needed to con- 
clude that the above specification entails def choose{S) <t4> ~^{S = empty). 

^ In this example, it is essential to choose a new name for our partial addi- 
tion operation. Otherwise, since is (rightly) declared as a total operation in 
Natural_WithJ3ound, the declaration op Nat x Nat Nat would 

be useless: the same name, same thing principle would lead to models with just 
one, total, addition operation. 
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4 Partial Functions 



To improve the clarity of specifications, it is in general advisable to specify 
definition domains as explicitly as possible, and Set_Partial_Choose_2 is 
somehow easier to understand than Set_Partial_Choose_3 (both specifica- 
tions define the same class of models) . 

spec Natural_Partial_Pre = 

Natural_Arithmetic 
then op pre : Nat Nat 

• ^ def pre{0) 

\/x : Nat • pre{suc{x)) = x 

end 

In the above example, one can consider that the domain of definition of pre 
is (exactly) specified in an explicit enough way, since the first axiom states 
exactly that pre(O) is undefined while the second one implies that pre is 
defined for all natural numbers of the form suc{x). 

spec Natural_Partial_Subtraction_1 = 

Natural_Partial_Pre 
then op Nat x Nat — *■? Nat 

Vz, y : Nat 

• X — 0 = X 

• X — suc{y) = pre{x — y) 

end 

The above specification is perfect from a mathematical point of view, but 
is clearly not explicit enough, since there is no easy way to infer when x — y \s 
defined. From a methodological point of view, the following alternative version 
is much better. 

spec Natural_Partial_Subtraction = 

Natural_Partial_Pre 
then op Nat x Nat -^1 Nat 

Vz, y : Nat 

• def{x — y) {y < X \f y = x) 

• X — 0 = X 

• X — suc{y) = pre{x — y) 

end 

The above examples clearly demonstrate why the explicit specification of 
definition domains is generally advisable from a methodological point of view. 
However, they also indicate that this recommendation should not be applied 
in too strict a way, and that deciding whether a specification is explicit enough 
or not is to some extent a matter of taste. 



4.2 Specifying Domains of Definition 
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Partial functions are minimally defined by default in free 
specifieations. 



spec List_Selectors_1 [sort Elem] = 

List [sort Elem] 

then free { ops head : List Elem] 
tail : List — >? List 
Ve : Elem] L : List 

• head(cons(e, L)) = e 

• tail {cons {e, L)) = L } 

end 

In the above example, the given axioms imply that head and tail are de- 
fined on lists of the form cons {e, L). The freeness constraint requires that these 
functions are minimally defined. Since the terms head{empty) and tail{empty) 
are not equated to any other term, the freeness constraint implies that these 
terms are undefined, and hence that the functions head and tail are unde- 
fined on empty. The situation here is similar to the fact that predicates hold 
minimally in models of free specifications (see Chap. 3, p. 38). 

spec List_Selectors_2 [sort Elem] = 

List [sort Elem] 
then ops head : List Elem] 
tail : List —>-7 List 
Ve : Elem] L : List 

• def head{empty) 

• ^ def tail{empty) 

• head(cons(e, L)) = e 

• tail(cons(e, L)) = L 

end 

The above specification List_Selectors_2 is an alternative to List_ 
Selectors_1; both specifications define exactly the same class of models. 
However, List_Selectors_2 is clearly easier to understand and can be con- 
sidered as technically simpler, since it involves no freeness constraint. 

Operations like head and tail are usually called selectors, and Case pro- 
vides abbreviations to specify selectors in a very concise way, as we see next. 
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4 Partial Functions 



4.3 Partial Selectors and Constructors 



Selectors can be specified concisely in datatype declarations, and are 
usually partial. 



spec List_Selectors [sort Elem] = 

free type List ::= empty \ cons{head :? Elem- tail :? List) 

The above free datatype declaration introduces, in addition to the con- 
structors empty and cons, two partial selectors head and tail yielding the 
respective arguments of the constructor cons. Hence, this free datatype decla- 
ration with selectors has exactly the same effect as the ordinary free datatype 
declaration free type List ::= empty \ cons{Elem] List), together with 
the operation declarations and axioms of List_Selectors_2 (i.e., List_ 
Selectors and List_Selectors_2 define exactly the same class of models). 
The following example is similar in spirit. 

spec Natural_Suc_Pre = free type Nat ::= 0 \ suc{pre :? Nat) 



V, 



Selectors are usually total when there is only one constructor. 



spec Pair_ 1 [sorts Eleml , Elem2] = 

free type Pair ::= pair(first : Eleml] second : Elem2) 

While selectors are usually partial operations when there is more than one 
alternative in the corresponding datatype declaration, they can be total, and 
this is generally the case when there is only one constructor, as in the above 
example. The free datatype declaration entails in particular axioms asserting 
that first and second yield the respective arguments of the constructor pair 
(i.e., first{pair{el , e2)) = el and second{pair{el , e2)) = e2). 




Constructors may be partial. 



spec Part .Container [sort Elem] = 
generated type 

P .Container ::= empty \ insert{Elem] P .Container)! 
pred addable : Elem x P.Container 
vars e, e' : Elem; C : P.Container 
• def insert{e, C) addable{e, C) 



4.4 Existential Equality 
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pred : Elem x P_Container 

• ^(e is -in empty) 

• (e is-in insert{e' , C) <t4> (e = e' V e is-in C)) if addable{e' , C) 

end 

The intention in the above example is to define a reusable specification of 
partial containers. The insert constructor is specified as a partial operation, 
defined if some condition on both the element e to be added and the container 
C to which the element is to be added holds. This condition is abstracted 
here in a predicate addable, so far left unspecified. Later on, instantiations 
of the Part .Container specification can be adapted to specific purposes by 
extending them with axioms defining addable. 

The above generated datatype declaration abbreviates as usual the dec- 
laration of a sort P -Container , a constant constructor empty, and a partial 
constructor insert : Elem x P-Container — >? P -Container . It also entails the 
corresponding generatedness constraint. 



4.4 Existential Equality 



Existential equality requires the definedness of both terms as well as 
their equality. 



spec Natural Jartial_Subtraction_2 = 

Natural Jartial_Subtraction_ 1 
then Vx, y, z : Nat • y — x = z — x^y = z 
%{ y — x = z — x^y = z would be wrong, 

def{y — x) /\ def{z — x) Ay — x = z — x=>y = z 
is correct, but better abbreviated in the above axiom }% 

end 

An existential equation tl = t2 is equivalent to def{tl) A def{t2) A 
tl = t2, so it holds if and only if both terms tl and t2 are defined and denote 
the same value. Existential equality '=’ is input as ‘=e=’. 

Note that while a trivial strong equation of the form t = t always holds, 
this is not the case for existential equations. For instance, the trivial existential 
equation x — y = x — y does not hold, since the term x — y may be undefined. 

In general consequences of imdefinedness are undesirable. Hence a con- 
ditional equation of the form tl = t2 ^ t3 = t4 is often wrong if tl and 
t2 may be undefined, because the equality t3 = t4 would be implied when 
both tl and t2 are undefined (since then the strong equation tl = t2 would 
hold). The above specification provides a typical example of such a situation: 
y — x = z — x^y = z would be wrong, since it would entail that any two 
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4 Partial Functions 



arbitrary values y and z are equal (it is enough to choose an x greater than 
y and z to make y — x and z — x both undefined) . 

Therefore, to avoid such undesirable consequences of undefinedness, it 
is advisable to use existential equations instead of strong equations in the 
premises of conditional equations involving partial operations. An alternative 
is to add the relevant definedness assertions explicitly to the equations in the 
premises. 



5 



Subsorting 



T_, 



Subsorts and supersorts are often useful in Casl specifications. 



Many examples naturally involve subsorts and supersorts. Casl provides 
means for the declaration of a sort as a subsort of another one when the values 
of the subsort are regarded a special case of those in the other sort. The aim of 
this chapter is to discuss and illustrate how to handle subsorts and supersorts 
in Casl specifications. 



5.1 Subsort Declarations and Definitions 



Subsort declarations directly express relationships between carrier 
sets. 



spec Generic_Monoid_ 1 [sort Elem] = 
sorts Elem < Monoid 
ops 1 : Monoid] 

Monoid X Monoid — > Monoid, assoc, unit 1 

end 

The above example declares the sort Elem to be a subsort of Monoid, or, 
symmetrically, the sort Monoid to be a supersort of Elem. Hence the spec- 
ification Generic_Monoid_1 is quite similar to the specification Generic. 
Monoid given in Chap. 3, p. 30, the only difference being the use of a subsort- 
ing relation between Elem and Monoid instead of an explicit inj operation to 
embed values of sort Elem into values of sort Monoid. 
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5 Subsorting 



In contrast to most other algebraic specification languages providing sub- 
sorting facilities, subsorts in Casl are interpreted by arbitrary embeddings 
between the corresponding carrier sets. In the above example, the subsort 
declaration Elem < Monoid induces an implicit (unnamed) embedding from 
the carrier of the sort Elem into the carrier of the sort Monoid. Thus the 
main difference between Generic_Monoid and Generic_Monoid_1 is that 
the embedding is explicit and named inj in Generic_Monoid while it is 
implicit in Generic_Monoid_1. 

Note that interpreting subsorting relations by embeddings rather than 
inclusions does not exclude models where the (carrier of the) subsort hap- 
pens to be a subset of (the carrier of) the supersort, and the embedding a 
proper inclusion. Embeddings are just slightly more general than inclusions, 
and technically not much more complex. 



Operations declared on a sort are automatically inherited by its 
subsorts. 



spec Vehicle = 

Natural 

then sorts Car, Bicycle < Vehicle 

ops max-speed : Vehicle — s- Nat', 

weight : Vehicle — *■ Nat', 

engine -Capacity : Car Nat 

end 

The above example introduces three sorts. Car, Bicycle and Vehicle, and 
declares both Car and Bicycle to be subsorts of Vehicle. A subsort declaration 
entails that any term of a subsort is also a term of the supersort, so here, any 
term of sort Car is also a term of sort Vehicle, and we can apply the operations 
max speed and weight to it (and similarly for a term of sort Bicycle). 

In other words, with the single declaration maxspeed : Vehicle Nat, 
we get the effect of having declared also two other operations, maxspeed : 
Car Nat and maxspeed : Bicycle — > Nat.^ 

Obviously, operations that are only meaningful for some subsort should 
be defined at the appropriate level. This is the case here for the operation 
engine -Capacity , which is only relevant for cars, and therefore defined with 
the appropriate profile exploiting the subsort Car. 



^ Strictly speaking, there is just one maxspeed operation in the signature of Vehi- 
cle. The difference between the kind of inheritance described here and operations 
actually declared on subsorts becomes important when writing symbol maps, see 
Chap. 7. 



5.1 Subsort Declarations and Definitions 
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V, 



Inheritance applies also for subsorts that are declared afterwards. 



spec More_Vehicle = Vehicle then sorts Boat < Vehicle 

The order in which a subsort and an operation on the supersort are de- 
clared is irrelevant. In More_Vehicle, we introduce a further subsort Boat 
of Vehicle, and as a consequence, we again get the effect of having both 
max^speed and weight available for boats, as was already the case for cars 
and bikes. 





Subsort membership can be checked or asserted. 



spec Speed_Regulation = 

Vehicle 

then ops speed Jimit : Vehicle —>■ Nat; 

car^speedJimit, bike speed Jimit : Nat 
\/v : Vehicle 

• V € Car speed Jimit{v) = car speed Jimit 

• V € Bicycle speed Jimit{v) = bike speed Jimit 

end 

A subsort membership assertion, written ‘t G s’, where t is a term and s 
is a sort, is a special kind of atomic formula: it holds if and only if the value 
of the term t is the embedding of some value of sort s. For instance, in the 
above example, v € Car holds if and only if v denotes a vehicle which is the 



embedding of a car value. Note that ‘€’ is input as ‘in’, but displayed as ‘€’ 


L 


Datatype declarations can involve subsort declarations. 


[ 





The sequence of declarations: 



sorts Car, Bicycle, Boat 

type Vehicle ::= sort Car \ sort Bicycle \ sort Boat 

is equivalent to the declaration sorts Car, Bicycle, Boat < Vehicle. There 
may be some values of sort Vehicle which are not the embedding of any value 
of sort Car, Bicycle, or Boat. Intuitively, the above datatype declaration just 
means that Vehicle ‘contains’ the union (which may not be disjoint) of Car, 
Bicycle and Boat. Note that the subsorts used in the datatype declaration 
must already be declared beforehand. 
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5 Subsorting 



The sequence of declarations: 

sorts Car, Bicycle, Boat 

generated type Vehicle ::= sort Car \ sort Bicycle \ sort Boat 

is more restrictive, since the generatedness constraint implies that any value 
of the supersort Vehicle must be the embedding of some value of the declared 
subsorts Car, Bicycle and Boat. Intuitively, the above datatype declaration 
means that Vehicle ‘is exactly’ the union (which again may not be disjoint) 
of Car, Bicycle and Boat. In particular, this declaration prevents subsequent 
introduction of further subsorts (unless the values of the new subsorts are 
intended to correspond to some values of the already declared subsorts). For 
instance, if we were now to extend the above specification with sorts Plane < 
Vehicle, all values of sort Plane would have to correspond to Car, Bicycle or 
Boat values (which is presumably not what we were intending). 

The sequence of declarations: 

sorts Car, Bicycle, Boat 

free type Vehicle ::= sort Car \ sort Bicycle \ sort Boat 

entails the same generatedness constraint as in the previous example, and, 
moreover, the freeness constraint requires that there is no ‘common’ value in 
the subsorts of Vehicle. Intuitively, the above declaration means that Vehicle 
‘is exactly’ the disjoint union of Car, Bicycle and Boat. This means in par- 
ticular that the introduction of a further common subsort of both Car and 
Boat (say, sorts Amphibious < Car, Boat) is impossible. 



Subsorts may also arise as classifications of previously specified 
values, and their values can be explicitly defined. 



spec Natural_Subsorts = 

Natural_Arithmetic 
then pred even : Nat 

• even(O) 

• ^ even{l ) 

Vn : Nat • even{suc{suc{n))) even{n) 
sort Even = {x : Nat • even{x)} 
sort Prime = {x : Nat • 1 < x A 

Vy, z : Nat • x = y* *z^y=l\/z=l} 

end 

The subsort definition sort Even = {x : Nat • even(x)} is equivalent to 
the declaration of a subsort Even of Nat (i.e., sorts Even < Nat) together 
with the assertion \/x : Nat • x G Even even{x). 



5.2 Subsorts and Overloading 
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The main advantage of defining the subsort Even in addition to the predi- 
cate even is that we may then use the subsort when declaring operations (e.g., 
op times2 : Nat — > Even) and variables. 

The subsort definition for Prime above illustrates that it is not always 
necessary to introduce and define an explicit predicate characterizing the val- 
ues of the subsort: the formula used in a subsort definition is not restricted 
to predicate applications. In fact whenever a (unary) predicate p on a sort s 
could be defined by pred p{x : s) ^ f for some formula /, we may instead 
define sort P = {x : s • /}, and use sort membership assertions t G P in- 
stead of predicate applications p{t), avoiding the introduction of the predicate 
p altogether. 

The following example is a further illustration of subsort definitions. We 
declare a subsort Pos of Nat and ensure that values of Pos correspond to 
non-zero values of Nat. (Several alternative ways of specifying the sort Pos 
will be considered later in this section.) 

spec Positive = 

Natural_Partial_Pre 
then sort Pos = {x : Nat • ~^(x = 0)} 



5.2 Subsorts and Overloading 



It may he useful to redeclare previously defined operations, using the 
new subsorts introduced. 


L 


[ 





spec 

then 



end 

Since, in Positive, we have defined Pos as a subsort of Nat, all operations 
defined on natural numbers, like sue, ‘-I-’ and (see Natural_Arithmetic 
in Chap. 3, p. 38, which is extended into Natural_Partial_Pre in Chap. 4, 
p. 52), are automatically inherited by Pos and can be applied to terms of sort 
Pos. However, according to their declarations, these operations, when applied 
to terms of sort Pos, yield results of sort Nat. To indicate that these results 
always correspond to values in the subsort Pos, it is necessary to explicitly 
overload these operations by similar ones with the appropriate profiles. This is 



Positive_Arithmetic = 

Positive 
ops 1 : Pos; 

sue : Nat Pos; 

__ + Pos X Pos — > Pos; 

__ -b : Pos X Nat Pos; 

__ -b — : Nat X Pos — > Pos 
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the aim of the first three lines of operation declarations in the above example. 
The last two operation declarations further overload ‘+’ to specify that ‘+’ 
also yields a result of sort Pos as soon as one of its arguments is a term of 
sort Pos. 

It is quite important to understand that the above overloading declarations 
are enough to achieve the desired effect, and that no axioms are necessary. 
The fundamental rule is that, in models of Casl specifications with subsort- 
ing, embedding and overloading have to be compatible: embeddings commute 
with overloaded operations. This can be rephrased into the following intuitive 
statement: If terms look the same, then they have the same value in the same 
sort. Thus, in our example, the value of ^ 1 + 1’ is the same in Nat whatever 
the combination of the overloaded constant ‘1’ and operation ‘-I-’ is chosen, 
and there is no need for any axiom to ensure this, since this is implicit in the 
semantics of subsorting. 



5.3 Subsorts and Partiality 



A subsort may correspond to the definition domain of a partial 
function. 



spec Positive_Pre = 

Positive_Arithmetic 
then op pre : Pos Nat 



Since we have introduced the subsort Pos of non-zero natural numbers, it 
makes sense to overload the partial pre operation on Nat by a total one on Pos, 
as illustrated above, to emphasize the fact that indeed pre is a total operation 
on its definition domain. Note again that no further axiom is necessary, and 
that the semantics of subsorting will ensure that both the partial and total 
pre operations will give the same value when applied to the same non-zero 
value. ^ 

1-, 



Using subsorts may avoid the need for partial functions. 



spec Natural_Positive_Arithmetic = 
free types Nat ::= 0 \ sort Pos; 

Pos ::= suc{pre : Nat) 

^ This should not be confused with the same name, same meaning principle, which 
does not apply here: the total pre and the partial one have different profiles, and 
hence are just overloaded. 



5.3 Subsorts and Partiality 
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ops 1 : Pos = suc{0); 

Nat X Nat — > Nat, assoc, comm, unit 0; 

: Nat X Nat Nat, assoc, comm, unit 1; 

__ + Pos X Pos Pos ; 

Pos X Nat — > Pos; 

Nat X Pos — > Pos 

Vz, y : Nat 

• X + suc{y) = suc{x + y) 

• X * 0 = 0 

• X * suc{y) = X + {x * y) 

end 

It is indeed tempting to exploit subsorting to avoid the declaration of par- 
tial functions, as illustrated by the above Natural_Positive_Arithmetic 
specification, which is an alternative to Positive_Pre and avoids the intro- 
duction of the partial predecessor operation. Note that in the above example, 
we have fully used the facilities for defining free datatypes with subsorts, and 
in particular non-linear visibility for the declared sorts, which allows us to 
refer to the subsort Pos in the first line before defining it in the second one. 

Avoiding the introduction of the partial predecessor operation has some 
drawbacks, since some previously well-formed terms (with defined values) have 
now become ill-formed, e.g., pre{pre {sue {!))), where pre{suc{l)) is a (well- 
formed) term of sort Nat but pre expects an argument of sort Pos . (The fact 
that pre{suc{l)) = f is a consequence of the specified axioms, and that 1 is 
of sort Pos, does not of course entail that pre{suc{l )) is of sort Pos too, since 
axioms are disregarded when checking for well-formedness.) See below for 
possible workarounds using explicit casts. Moreover, it is not always possible, 
or easy, to avoid the declaration of partial operations by using appropriate 
subsorts — ^just consider, e.g., subtraction on natural numbers. 

As a last remark on this issue, the reader should be aware of the fact that, 
while overloading a partial operation on a supersort (say, pre on Nat) with a 
total one on a subsort {pre on Pos) is fine, overloading a total operation on 
a supersort with a partial one on a subsort forces the partial operation to be 
total, and hence, the latter would be better declared as total too.^ 



Casting a term from a supersort to a subsort is explicit and the value 
of the cast may be undefined. 


L 


[ 





® Overloading a total cons on List with a partial cons on the subsort OrderedList 
would either lead to a total cons operation on OrderedList, or to an inconsis- 
tent specification, depending on how the definition domain of the partial cons is 
specified. 
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In Casl, a term of a subsort can always be considered as a term of any 
supersort, and embeddings are implicit. On the contrary, casting a term from 
a supersort to a subsort is explicit, and since casting is essentially a partial op- 
eration, the resulting casted term may not denote any value. Casting a term t 
to a sort s is written t as s. Consider the term pre{ pre{suc{l )) as Pos ) which 
is well-formed in the context of the Natural_Positive_Arithmetic speci- 
fication. This term does indeed denote a value, but the value is not a positive 
natural number, so the value of the term pre{ pre{suc{l )) as Pos ) as Pos is 
undefined. 

Note that def {t as s) is equivalent to t G s, for a well- formed term t of a 
supersort of s. 



Supersorts may be useful when generalizing previously specified sorts. 



spec 

then 



end 

The specification Integer_Arithmetic_ 1 extends Natural_Positive_ 
Arithmetic and defines the sort Int as a supersort of the sort Nat. As a 
consequence, terms which have two parses in sort Int, depending whether the 
embedding from Nat to Int is applied to the arguments or to the result of 
overloaded operations, are required by the semantics of subsorting to have the 
same value for both parses, and they can therefore be used without explicit 
disambiguation. 



Integer_Arithmetic_1 = 
Natural_Positive_Arithmetic 



free type Int ::= sort Nat \ - 


-—{Pos) 


ops __ 4- : Int x Int — 


Int, 


assoc, comm, unit 0 


Int X Int — 


Int] 




: Int X Int — 


Int, 


assoc, comm, unit 1 


abs : Int — *■ Nat 







\/x : Int', n : Nat] p, q : Pos 

• suc{n) -I- (— I ) = n 

• suc{n) + (—suc(q)) = n + (—q) 

• i~P) + i-d) = -{p + d) 

• X — 0 = X 

• X — p = X + {—p) 

• X — {—q) = X + q 

• 0 * {—q) = 0 

• P* {-d) = ~{P * d) 

• i-p) * {-d) =P* d 

• abs{n) = n 

• abs{—p) = p 



5.3 Subsorts and Partiality 
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The situation would be quite different if one would be using a combination 
of Natural_Arithmetic and Integer_Arithmetic (see Chap. 3), say by 
extending both in a structured specification (see the next chapter for more 
details on structured specifications). In such a combination, a term such as 
suc{0) would have two parses, one in sort Nat and one in sort Int] in the 
absence of any subsort declaration relating Nat and Int, and hence of any 
implicit embedding, this term would then be ambiguous, and would require 
explicit disambiguation to become a well-formed term. 



Supersorts may also be used for extending the intended values by new 
values representing errors or exceptions. 



spec Set_Error_Choose [sort Elem] = 

Generated_Set [sort Elem] 
then sorts Elem < ElemError 

op choose : Set —>■ ElemError 
pred __is-in__ : ElemError x Set 

\/S : Set • ^{S = empty) choose(S) € Elem A choose(S) isJn S 

end 

The above specification Set_Error_Choose is another variant of the 
various specifications of sets equipped with a partial choose function given in 
Chap. 4. This variant avoids the declaration of a partial function choose by 
using instead a supersort of Elem, namely ElemError, as the target sort of 
choose. The idea here is that values of ElemError which are not (embeddings 
of) values of Elem represent errors, e.g., the application of choose to the 
empty set. Note that to obtain the desired effect, it is necessary to explicitly 
state that choose{S) € Elem when S is not the empty set; moreover, to make 
the term choose{S) isjin S well-formed, we have to explicitly overload the 
predicate -is-in__ : Elem x Set provided by Generated_Set by a predicate 
-jisjin __ : ElemError x Set as shown above. This example demonstrates that 
avoiding partial functions by the use of ‘error supersorts’ is not as innocuous 
as it may seem, since in general one would need to enlarge the signatures 
considerably by adding all required overloadings. 

spec Set_Error_Ghoose_ 1 [sort Elem] = 

Generated_Set [sort Elem] 
then sorts Elem < ElemError 

op choose : Set —>■ ElemError 

yS : Set • ^{S = empty) {choose(S) as Elem) isJn S 

end 

The specification Set_Error_Ghoose_1 above is a last attempt to avoid 
the use of partial functions; again, we introduce a supersort ElemError as 
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in Set_Error_Choose, but to avoid the need for overloading the predicate 
is jin, we explicitly cast the term choosers) in {choosers) as Elem) isJn S. 
Note that when, for some value of S, (choosers) as Elem) is jin S holds, this 
implies that choosers) as Elem is defined, and hence that choose{S) € Elem 
holds as well. This last version may seem preferable to the previous one. 
However, one should be aware that here, despite our attempt to avoid the use 
of partial functions, we rely on explicit casts, hence on terms that may not 
denote values: partiality has not been eliminated, the partial functions have 
merely been factorized as compositions of total functions with casting. 



6 



Structuring Specifications 



Large and complex specifications are easily built out of simpler ones 
by means of (a small number of) specification-building operations. 



In the previous chapters, we have focused attention on basic specifications 
and detailed how to use the various constructs of Casl to write meaningful, 
but relatively simple, specifications. The aim of this chapter is to discuss and 
illustrate how to assemble simple pieces of specifications into more complex, 
structured ones. In particular we explain how to extend specifications, make 
the union of several specifications, as well as how to rename or hide symbols 
when assembling specifications. Parametrization and instantiation of generic 
specifications are explained in the next chapter. 



6.1 Union and Extension 



v, 



Union and extension can be used to structure specifications. 



spec List_Set [sort Elem] = 

List_Selectors [sort Elem] 
and Generated_Set [sort Elem] 
then op elements -of : List — > Set 
Ve : Elem; L : List 

• elements-of empty = empty 

• elements -of cons(e, L) = {e} U elements -of L 

end 



M. Bidoit and P.D. Mosses: CASL User Manual, LNCS 2900, pp. 67-75, 2004. 
(c) IFIP International Federation for Information Processing 2004 
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The above example shows how to make the union (expressed by ‘and’) 
of two specifications List_Selectors (see Chap. 4, p. 54) and Generated. 
Set (see Chap. 3, p. 35), and then further extend this union by an operation 
and some axioms (using ‘then’). Union and extension are the most commonly 
used specification-building operations. In contrast with extension, whose pur- 
pose is to extend a given piece of specification by new symbols and axioms, 
union is generally used to combine two self-contained specifications. Union of 
specifications is obviously associative and commutative. 

All symbols introduced by a specification are by default exported by it 
and visible in its extensions or in its unions with other specifications. (Vari- 
ables are not considered as symbols, and never exported.) Remember also the 
‘same name, same thing' principle: in the above List.Set specification, it is 
therefore the same sort Elem which is used to construct both lists and sets.^ 



Specifications may combine parts with loose, generated, and free 
interpretations. 



spec List.Choose [sort Elem] = 

List_Selectors [sort Elem] 
and Set_Partial_Choose_2 [sort Elem] 
then ops elements -of : List — > Set; 
choose : List Elem 
Ve : Elem; L : List 

• elements-of empty = empty 

• elements -of cons{e, L) = {e} U elements -of L 

• def choose(L) ~^{L = empty) 

• choose(L) = choose{elements -of L) 

end 

spec Set.toUjIST [sort Elem] = 

List_Set [sort Elem] 
then op list-of __ : Set — > List 

yS : Set • elements -of {list _of S) = S 

end 

The specification List.Choose is built as an extension of the union of 
List_Selectors and Set Jartial_Choose_2 (see Chap. 4, p. 50). This 
extension introduces an operation elements-of (as in List.Set) and a partial 
operation choose, which are defined by some axioms. In List.Selectors, 
lists are defined by a free datatype construct (with selectors), hence have a 

^ The constant empty is overloaded, since we have a constant empty : List for lists 
and a constant empty : Set for sets. 



6.2 Renaming 
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free interpretation. Set_Partial_Choose_2 is itself an extension of (Set_ 
Partial_Choose which is an extension of) Generated_Set, where sets are 
defined by a generated datatype construct. However, note that as discussed in 
Chap. 3, p. 35, the apparently loose specification Generated_Set is in fact 
not so. Moreover, the choose partial function on sets is loosely defined in Set_ 
Partial_Ghoose_2, and so is therefore also the choose partial function on 
lists defined in List_Ghoose. It is easy to see that the operation elements-of 
is uniquely defined. The sort Elem has of course a loose interpretation. 

Thus the specification List_Ghoose combines parts with a free interpre- 
tation, parts with a generated interpretation, and parts with a loose interpre- 
tation. The situation is similar to that with List_Set (and Set_to_List), 
where the operation list^of is loosely defined with the help of the operation 
elements -of . 



6.2 Renaming 



Renaming may be used to avoid unintended name clashes, or to 
adjust names of sorts and change notations for operations and 
predicates. 



spec Stack [sort Elem] = 

List_Selectors [sort Elem] with sort List i— > Stack, 

ops cons ^ push __onto—, 
head top, 
tail 1-^ pop 

end 

While the ‘same name, same thing’ principle has proven to be appropri- 
ate in numerous examples given in the previous chapters and above, it may 
still happen that, when combining specifications, this principle leads to unin- 
tended name clashes. An unintended name clash arises for instance when one 
combines two specifications that both export the same symbol (with the same 
profile in case of an operation or a predicate) , while this symbol is not intended 
to denote the same ‘thing’ in the combination. In such cases, it is necessary 
to explicitly rename some of the symbols exported by the specifications put 
together in order to avoid the unintended name clashes. 

When reusing a named specification, it may be convenient to rename some 
of its symbols; moreover, in the case of operation or predicate symbols, one 
may also change the style of notation. This is illustrated in the specifica- 
tion Stack above which is obtained as a renaming of the specification List_ 
Selectors. (A renaming is introduced by the keyword ‘with’.) First, the sort 
List is renamed into Stack, then the operation cons is renamed into a mixfix 
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operation push__onto—, and finally the selectors head and tail are renamed 
into top and pop, respectively. Note that ‘i— >’ is input as ‘ I 

The user only needs to indicate how symbols provided by the renamed 
specification are mapped to new symbols. A signature morphism is auto- 
matically deduced from this ‘symbol map’. For instance, the signature mor- 
phism inferred from the symbol map specified in Stack maps the operation 
symbol cons : Elem x List — > List to the operation symbol push__onto— : 
Elem X Stack Stack: not only the operation name is changed, but also its 
profile according to the renaming of List into Stack. 

In a symbol map, one can qualify the symbol to be renamed by its kind, 
using the keywords sort, op, and pred (or their plural forms), as appropriate; 
this is illustrated in Stack above. Qualification in symbol maps is generally 
recommended since it improves their readability. 

While it is possible to change the syntax of an operation or predicate 
symbol, as illustrated above for cons mapped to push__onto—, it is not possible 
to change the order of the arguments of the renamed operation or predicate. 

In general, one does not need to rename all the symbols provided by the 
specification to be renamed. In the symbol map describing the intended re- 
naming, it is indeed enough to mention only the symbols that change. By 
default, any symbol not explicitly mentioned is left unchanged (although its 
profile may be updated according to the renaming specified for some sorts). 
This is illustrated here in Stack where there is no need to rename the constant 
empty, which will therefore have the same name for both lists and stacks. How- 
ever, the induced signature morphism maps the constant symbol empty : List 
into the constant symbol empty : Stack. 

One can also explicitly rename a symbol to itself, say by writing ‘‘empty i-^ 
empty’, or just mention it without providing a new name, as in ‘with empty’ , 
which is equivalent to ‘with empty i— > empty’ . 

By default, overloaded symbols are renamed simultaneously. For instance, 
in Integer_Arithmetic_1 with __-f plus, all the five overloaded infix 
‘-I-’ operations exported by Integer_Arithmetic_1 (see Chap. 5, p. 64) are 
renamed into five plus operations, with a functional syntax and the appropri- 
ate profiles. 

In general, it is possible to specifically rename one of some overloaded sym- 
bols, by specifying its profile in the symbol map. For instance, in List_Set 
with empty : List i-^ nil, only the constant empty of sort List is renamed into 
nil, while the constant empty of sort Set remains unchanged. However, care is 
needed in the presence of subsorts, since the signature morphism induced by 
the specified symbol map should preserve the overloading relations associated 
with subsorts. For instance, if we attempt to only rename in the specification 
Integer_Arithmetic_1 the addition ‘-I-’ of two positive numbers into plus 
and write Integer_Arithmetic_1 with Pos x Pos — *■ Pos plus, 

we merely obtain an ill-formed specification. Thus in the specification Inte- 
GER_Arithmetic_1, all the five overloaded ‘-I-’ operations must be renamed 
simultaneously, again into five overloaded symbols. 



6.3 Hiding 
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When combining specifications, origins of symbols can be indicated. 



spec List_Set_ 1 [sort Elem] = 

List_Selectors [sort Elem] with empty, cons 
and Generated_Set [sort Elem] with empty, {— }, __ U__ 
then op elements -of : List — > Set 
Ve : Elem; L : List 

• elements-of empty = empty 

• elements -of cons{e, L) = {e} U elements -of L 

end 

Since, as explained above, ‘with empty, cons' means ‘with empty i— > 
empty, cons i— > cons’, identity renaming can be used just to emphasize the 
fact that a given specification exports some symbols. This is illustrated in the 
specification List_Set_1 above, which is quite similar to List_Set, but for the 
fact that here we emphasize that List_Selectors exports in particular the 
operations empty and cons, and that Generated_Set exports in particular 
the operations empty, and ‘U’. 



6.3 Hiding 



Auxiliary symbols used in structured specifications can be hidden. 



spec Natural_Partial_Subtraction_3 = 

Natural_Partial_Subtraction_ 1 hide sue, pre 

end 

spec Natural_Partial_Subtraction_4 = 
Natural_Partial_Subtraction_ 1 
reveal A^at, 0 , 1 , 

end 

When writing large specifications, it is quite frequent to rely on auxiliary 
operations (and predicates) to specify the operations (and predicates) of in- 
terest. Once these are defined, the auxiliary operations are no longer needed, 
and are better removed from the exported signature of the specification, which 
should include only the symbols that were required to be specified. This is the 
purpose of the hide construct. 

Consider for instance the specification Natural_Partial_Subtraction_ 
1 given in Chap. 4, p. 52. Once addition and subtraction are defined, the 
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two basic operations sue and pre are no longer needed (since suc{x) is more 
conveniently written x + 1, and similarly pre{x) is expressed by x — 1), and 
can therefore be hidden. This is illustrated by the specification Natural. 
Partial_Subtraction_3 given above. 

Depending on the relative proportion of symbols to be hidden or not, in 
some cases it may be more convenient to explicitly list the symbols to be 
exported by a specification rather than those to be hidden. The construct 
‘reveal’ can be used for that purpose, and ‘hide’ and ‘reveal’ are just two 
symmetric constructs to achieve the same effect. The use of ‘reveal’ is il- 
lustrated in Natural_Partial_Subtraction_4 above, and the reader can 
convince himself that both Natural Jartial_Subtraction_3 and Natu- 
ral Jartial_Subtraction_4 export exactly the same symbols. However, 
in this case the first specification is clearly more concise. A more convincing 
example of the use of ‘reveal’ is provided by the following example. 

spec Partial_Order_2 = Partial.Order reveal pred __ < __ 

Similar rules to the ones explained for renaming apply to the hide and 
reveal constructs. One can qualify a symbol to be hidden or revealed by its 
kind (sort, op or pred), and by default, overloaded symbols are hidden (or 
revealed) simultaneously. 

Note that hiding a sort entails hiding all the operations or predicates that 
use it in their profile. Similarly, revealing an operation or a predicate entails 
revealing all the sorts involved in its profile. For instance, in the specification 
Partial_Order_2 above, revealing the predicate ‘<’ entails revealing also 
the sort Elem. 

As a consequence, hiding sorts should be used with care in the presence 
of subsorts. For instance, hiding the sort Nat in the specification Positive 
given in Chap. 5, p. 61, leads to a specification of positive natural numbers 
with a sort Pos which has the expected carrier set, but without any operation 
or predicate available on it. Hiding the sort Nat in the specification Posi- 
tive_Arithmetic (see Chap. 5, p. 61) may seem more appropriate, but one 
should still note that the predicate ‘<’ is no longer available in Positive. 
Arithmetic hide sort Nat. 

As a last remark, note that when convenient, reveal can be combined 
with a renaming of (some of) the exported symbols. For instance, in the 
above Partial.Order.2 specification, we could have written ‘reveal pred 
.. < .. 1 -^ leq’ if, in addition to a restriction of the signature of Partial. 
Order, we wanted to rename the infix predicate ‘.. < ..’ into a predicate leq 
with a functional notation. 



6.4 Local Specifications 
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Auxiliary symbols can be made loeal when they do not need to be 
exported. 



spec List_Order [Total_Order with sort Elem, pred __ < __] = 
List_Selectors [sort Elem] 
then local op insert : Elem x List — > List 
Ve, e' : Elem- L : List 

• insert{e, empty) = cons{e, empty) 

• ins ert(e, cons (e', L)) = cons(e', insert (e, L)) when e' < e 

else cons{e, cons{e' , L)) 

within op order : List — > List 
Ve : Elem; L : List 

• order{empty) = empty 

• order{cons{e, L)) = insert{e, order{L)) 

end 



In many cases, auxiliary symbols are introduced for immediate use, and 
they do not need to be exported by the specification where they are declared. 
Then the best is to limit the scope of the declarations of such auxiliary symbols 
by using the ‘local . . . within . . . ’ construct. This is illustrated in the above 
specification List_Order, where the insert operation is introduced only for 
the purpose of the axiomatization of order. The declaration of insert has its 
scope limited to the part that follows ‘within’, and insert is therefore not 
exported by the specification List_Order. 

It is generally advisable to ensure that auxiliary symbols are declared in 
local parts of specifications. 

spec List_Order_Sorted 

[Total_Order with sort Elem, pred __ < __] = 

List_Selectors [sort Elem] 
then local pred ^Assorted : List 
Ve, e' : Elem] L : List 

• empty issorted 

• cons(e, empty) issorted 

• cons{e, cons{e' , L)) is sorted 

cons{e' ,L) issorted A ~^{e' < e) 
within op order : List — > List 

VL : List • order{L) issorted 

end 



The specification List_Order_Sorted above is a variant of the specifi- 
cation List_Order illustrating again the use of the ‘local . . . within . . . 
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construct - this time to declare an auxiliary predicate. (Actually, the two 
specifications are not equivalent, since List_Order_Sorted is much looser 
and only requires that order (L) is a sorted list, but perhaps not with the same 
elements as L.) 



Care is needed with loeal sort declarations. 



spec Wrong_List_Order_Sorted 

[Total_Order with sort Elem, pred __ < __] = 

List_Selectors [sort Elem] 
then local pred __issorted : List 

sort SortedList = {L : List • L issorted} 

Ve, e' : Elem; L : List 

• empty issorted 

• cons{e, empty) issorted 

• cons(e, cons(e' , L)) is-sorted 

cons(e',L) issorted A ~^{e' < e) 
within op order : List — > SortedList 

end 

Note that the above specification Wrong_List_Order_Sorted, which 
may at first glance be considered as a slight variant of List_Order_Sorted, 
is ill-formed: order is exported by Wrong_List_Order_Sorted, and hence 
all sorts occurring in its profile should also be exported, which cannot be, 
since the sort SortedList is auxiliary. So, if the specifier really intends to insist 
that the result sort of order is SortedList, this subsort should be exported, as 
shown below. 

spec List_Order_Sorted_2 

[Total_Order with sort Elem, pred __ < __] = 

List_Selectors [sort Elem] 
then local pred __issorted : List 
Ve, e' : Elem] L : List 

• empty issorted 

• cons{e, empty) issorted 

• cons(e, cons(e' , L)) is-sorted 

cons(e',L) issorted A ~^{e' < e) 
within sort SortedList = {L : List • L issorted} 
op order : List — > SortedList 

end 

In fact the ‘local . . . within . . . ’ construct abbreviates a combination 
of extension and explicit hiding. The specification List_Order_Sorted_2 
above, for instance, abbreviates: 
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spec List_Order_Sorted_3 

[Total_Order with sort Elem, pred __ < __] = 

List_Selectors [sort Elem] 
then { pred __is sorted : List 

Ve, e' : Elem; L : List 

• empty issorted 

• cons(e, empty) issorted 

• cons(e, cons(e' , L)) issorted 4^ 

cons(e',L) issorted A ^(e' < e) 
then sort SortedList = {L : List • L issorted} 
op order : List — > SortedList 
} hide .assorted 

end 

The main advantage of using the ‘local . . . within . . . ’ construct is that 
hiding the symbols introduced in the local part is left implicit. The conve- 
nience of this generally outweighs the danger of overlooking a locally-declared 
sort that is needed for the profile of an exported symbol. In any case, Case 
allows both styles, and users can simply choose the one they prefer. 



6.5 Named Specifications 



Naming a specification allows its reuse. 


L 


[ 





It is in general advisable to define as many named specifications as felt 
appropriate, since this improves the reusability of specifications: a named 
specification can easily be reused by referring to its name. 

Not only do the names serve as abbreviations when writing specifications, 
they also make it easy for readers to notice reuse. Moreover, when the name 
of a specification is aptly chosen, e.g., Natural_Arithmetic, readers may 
well be able to guess its signature - and perhaps even the specified axioms ~ 
from the name itself. (In Chap. 9, we shall see how named specifications and 
other items can be collected in libraries, and particular versions of them made 
available for use over the Internet.) 

References to named specifications are particularly convenient for specifi- 
cations structured using unions and extensions, where verbatim insertion of 
unnamed specifications would tend to obscure the structure. When needed, 
the signature of a referenced specification can be adjusted through appropri- 
ate combinations of renaming and hiding (although this should not often be 
necessary, provided that auxiliary symbols are made local, as explained in the 
previous section). 
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Generic Specifications 



Making a specification generic (when appropriate) improves its 
reusability. 



As mentioned in the previous chapter, naming specifications is a good 
idea. In many cases, however, datatypes are naturally generic, having sorts, 
operations, and/or predicates that are deliberately left loosely specified, to be 
determined when the datatype is used. For instance, datatypes of lists and 
sets are generic regarding the sort of elements. Generic specifications allow the 
genericity of a datatype to be made explicit by declaring parameters when the 
specification is named: in the case of lists and sets, there is a single parameter 
that simply declares the sort Elem.^ A fitting argument specification has 
to be provided for each parameter of a generic specification whenever it is 
referenced; this is called instantiation of the generic specification. 

The aim of this chapter is to discuss and illustrate how to define generic 
specifications and instantiate them. We have seen plenty of simple examples 
of generic specifications and instantiations in the previous chapters. In more 
complicated cases, however, explicit fitting symbol maps may be required 
to determine the exact relationship between parameters and arguments in 
instantiations, and so-called imports should be separated from the bodies of 
generic specifications. 

^ Generic specifications are also useful to ensure loose coupling between several 
named specifications, replacing an explicit extension by a parameter including 
only the necessary symbols and their required properties. This is illustrated in 
the Steam-Boiler Control System case study, see Chap. 13. 
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7.1 Parameters and Instantiation 



v, 



Parameters are arbitrary specifications. 



Any specification, named or not, can be used as the parameter of a generic 
specification. Commonly, the parameter is a rather trivial specification con- 
sisting merely of a single sort declaration, as in most of the examples given in 
the previous chapters, e.g.: 

spec GeneriC-Monoid [sort Elem] = %{ See Chap. 3, p. 30 }% 

spec List_Selectors [sort Elem] = %{ See Chap. 4, p. 54 }% 

However, the parameter can also be a more complex, possibly structured, 
specification, as in: 

spec List_Order [Total_Order with sort Elem, pred __ < __] = 
%{ See Chap. 6, p. 73 }% 

Recall that ‘with’ requires the signature of the specification to include the 
listed symbols; here, in fact, the signature of Total_Order does not contain 
any further symbols, so those are all the symbols that have to be supplied 
when instantiating List_Order. 



The argument specification of an instantiation must provide symbols 
corresponding to those required by the parameter. 



spec List_Order_Nat = List_Order [Natural_Order] 

The correspondence between the symbols provided by the argument spec- 
ification and those required by the parameter can be described by a fitting 
symbol map or left implicit when it is not ambiguous, which is often the case. 

In the above example, the argument specification Natural_Order pro- 
vides the sort Nat, the operation symbols 0 and sue, and the binary predicate 
symbol ‘<’. Hence this specification indeed provides symbols corresponding 
to those required by the parameter specification Total_Order and the cor- 
respondence can be left implicit because the argument Natural_Order has 
only single symbols of the right kind. (The coincidence of the predicate sym- 
bol in the parameter and argument is irrelevant here.) 

How to describe explicit fitting symbol maps and when they can be omitted 
is detailed later in this section. 
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The argument specification of an instantiation must ensure that the 
properties required by the parameter hold. 



spec Nat_Word = GenericJvIonoid [Natural] 

A (fitting) signature morphism from the signature of the parameter part to 
the signature of the argument specification is automatically deduced, taking 
into account the explicitly specified fitting symbol map if any (the situation 
here is quite similar to a renaming, where a signature morphism is deduced 
from a symbol map). The instantiation is defined if all models of the argument 
specification, when reduced along the induced fitting signature morphism, 
provide models of the parameter part. In particular the symbols provided 
by the argument specification must have the properties, if any, specified in 
the parameter for their counterparts. When this is the case, we get not only 
a signature morphism, but also a (fitting) specification morphism from the 
argument specification to the parameter specification.^ 

In the above Nat_Word example, since the parameter of Generic. 
Monoid is trivial, it is obvious that the instantiation is defined. 

The effect of the instantiation is to make the union of the argument spec- 
ification and of the (non generic equivalent of the) generic specification, re- 
named according to the induced fitting signature morphism. In particular, a 
side-effect of the instantiation is to rename the symbols of the generic specifica- 
tion according to the fitting signature morphism induced by the instantiation. 
In our Nat.Word example, the operation symbol inj : Elem — > Monoid is 
renamed into inj : Nat —>■ Monoid, while the operation symbols ‘7’ and 
are left unchanged (as well as the sort Monoid). Thus, the specification Nat_ 
Word abbreviates the following specification: 

Natural and { Non.GenericJMonoid with Elem i— > Nat }. 

When convenient, the instantiation can be completed by a renaming, as 
illustrated in the following variant of Nat.Word. 

spec Nat_Word_1 = 

Generic-Monoid [Natural] 
with Monoid i— *■ Nat -Word 

end 

In the case of the specification List_Order_Nat above, checking the de- 
finedness of the instantiation corresponds to a non-trivial proof obligation. 
The instantiation is defined since the predicate '<’ provided by Natural. 
Order is indeed a total ordering relation, hence the properties required by 

^ Note that consistency is entirely orthogonal to definedness: a defined instantiation 
may be consistent or not. 
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Total_Order are fulfilled, even if there is no syntactic correspondence be- 
tween the axioms given in Total_Order and those in Natural_Order. 





There must be no shared symbols between the argument specification 
and the body of the instantiated generic specification. 



spec ThisJs_Wrong = Generic_Monoid [Monoid] 

The intention in the above example may have been to specify monoids 
of monoids. However, the above instantiation is ill-formed since the sort 
Monoid and the operation symbols ‘T and are shared between the body 
of the generic specification Generic_Monoid and the argument specification 
Monoid. 

Section 7.3 provides useful hints on how to structure generic specifications 
in order to avoid as far as possible undesirable clashes of symbols in instanti- 
ations. A correct specification of monoids of monoids is provided in Sect. 7.2, 

p. 86. 



In instantiations, the fitting of parameter symbols to identical 
argument symbols can be left implicit. 



spec Generic_Gommutative_Monoid [sort Elem] = 

GeneriC-Monoid [sort Elem] 
then . . . 

When the parameter and the argument have symbols in common, these 
parameter symbols are implicitly taken to fit directly to the corresponding ar- 
gument symbols. Thus it is never necessary to make explicit that a symbol is 
mapped identically. In the above example, for instance, the parameter specifi- 
cation of GeneriC-Monoid is exactly the same as the argument specification 
in its instantiation, so the fitting can be left implicit. 



The fitting of parameter sorts to unique argument sorts can also be 
left implicit. 



When the argument specification has only a single sort, the fitting of all 
parameter sorts to that sort is obvious, and can again be left implicit, as 
illustrated earlier by the Nat_Word specification. Of course, this does not 
apply the other way round: if the parameter has a single sort (which is often 
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the case in practice) but the argument specification has more than one sort, 
the parameter sort could be mapped to any of the argument sorts, so the 
fitting symbol map has to be made explicit - except when the parameter sort 
is identical to one of the argument sorts, as previously explained, or when the 
fitting of sorts can be implied from the fitting of other symbols, as explained 
below. 





Fitting of operation and predicate symbols can sometimes be left 
implicit too, and can imply fitting of sorts. 



spec List_Order_Positive = List_Order [Positive] 

Fitting of operation and predicate symbols can imply fitting of sorts. For 
instance, when a parameter predicate symbol is fitted to an argument predi- 
cate symbol whose profile involves different sorts, this implies that the param- 
eter sorts involved have to be fitted to the corresponding sorts in the argument 
specification. 

This is illustrated in the above List_Order_Positive specification. In a 
first step, the fitting of the parameter sort Elem to one of the argument sorts 
Nat and Pos provided by the specification Positive (see Chap. 5, p. 61) may 
seem ambiguous. However, no explicit fitting of symbols is necessary here, 
since the argument specification provides only one binary predicate symbol, 
and the fitting of the corresponding binary predicate symbol of the parameter 
specification to it entails the fitting of the sort Elem to the sort Nat (Again, 
the coincidence of the predicate symbol in the parameter and argument is 
irrelevant here.) 

As may be clear by now, the exact rules for when the fitting between pa- 
rameter and argument symbols can be left implicit are quite sophisticated. It 
seems best to make the intended fitting explicit whenever it is not completely 
obvious, using the notation for fitting arguments illustrated in the following 
examples. 



The intended fitting of the parameter symbols to the argument 
symbols may have to be specified explicitly. 



spec Nat_Word_2 = 

GeneriC-Monoid [Natural_Subsorts fit Elem i-^ Nat] 

The correspondence between the symbols required by the parameter and 
those provided by the argument specification can be made explicit using so- 
called fitting symbol maps. For instance, the above Nat_Word_2 specifica- 
tion, which differs from Nat_Word only regarding the presence of subsorts of 
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Nat^ is obtained as an instantiation of Generic_Monoid, fitting the param- 
eter part ‘sort Elem' to the Natural_Subsorts specification. The mapping 
between the parameter sort Elem and the sort Nat provided by Natural. 
Subsorts is described by the fitting symbol map ‘fit Elem Nat’. 



V, 



A generic specification may have more than one parameter. 



spec Pair [sort Eleml ] [sort Elem2] = 

free type Pair ::= pair(first : Eleml] second : Elem2) 

Using several parameters is merely a notational convenience, since they 
are equivalent to their union. For instance, the above Pair specification is 
nothing but a variant of the specification Pair.I with just one parameter 
‘sorts Eleml, Elem2’ defined in Chap. 4, p. 54. 

Note that writing: 

spec Homogeneous Jair_1 [sort Elem] [sort Elem] = 
free type Pair ::= pair(first : Elem; second : Elem) 

merely defines pairs of values of the same sort, and HomogeneousJair.I 
is (equivalent to and) better defined as follows: 

spec HomogeneousJair [sort Elem] = 

free type Pair ::= pair(first : Elem; second : Elem) 

since the two parameters in Homogeneous_Pair_ 1 are equivalent to just one 
‘sort Elem’ parameter. 

From a methodological point of view, it is generally advisable to use as 
many parameters as convenient: the part of the specification that is intended 
to be specialized at instantiation time is better split into logically coherent 
units, each one corresponding to a parameter. Consider for instance: 

spec Table [sort Key] [sort Val] = ... 

Here, using two parameters in Table emphasizes that Key and Val are 
logically distinct entities which can be specialized as desired independently of 
each other. 



Instantiation of generic specifications with several parameters is 
similar to the case of just one parameter. 



spec PairJN^atural.Color = 

Pair [NaturalU\.rithmetic] [Color fit Elem2 RGB] 
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In the above example, the first parameter ‘sort Eleml ’ of Pair is instan- 
tiated by Natural_Arithmetic, which exports only one sort Nat, hence no 
explicit fitting symbol map is necessary. The second parameter ‘sort Elem2' 
of Pair is instantiated by Color: in this case a fitting symbol map must be 
provided, since Color exports two sorts, RGB and CMYK . 

Using the specification Pair_ 1 would require us to write: 

spec PairJN^atural_Color_1 = 

Pair_1 [Natural_Arithmetic and Color 
fit Eleml 1 -^ Nat, Elem2 RGB ] 

which clearly demonstrates the benefit of using two parameters as in Pair 
instead of just one as in Pair_1. 

When parameters are trivial ones (i.e., just one sort), one can always avoid 
explicit fitting maps. Consider for instance the following alternative to Pair_ 
Natural_Color: 

spec PairJMatural_Color_2 = 

Pair [sort Nat] [sort RGB] 
and Natural_Arithmetic and Color 

This may be convenient when the argument specification exports several 
sorts. Compare for instance: 

spec Pair_Pos = 

Homogeneous_Pair [sort Pos] and Integer_Arithmetic_1 

with: 

spec Pair_Pos_1 = 

Homogeneous_Pair [ Integer_Arithmetic_ 1 fit Elem I— !■ Pos ] 
Note that the instantiation: 

Homogeneous_Pair_1 [Natural] [Color fit Elem RGB] 
is ill-formed, since it entails mapping the sort Elem to both Nat and RGB. 

More generally, care is needed when the several parameters of a generic 
specification share some symbols, which in general is not advisable. 

As a last remark, note that it is easy to specialize a generic specification 
with several parameters, using a ‘partial instantiation’, as in the following 
version of Table: 

spec My_Table [sort Val] = 

Table [Natural_Arithmetic] [sort Val] 

where we still have a parameter for the values to be stored, but have decided 
that the keys are natural numbers. 
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Composition of generic specifications is expressed using instantiation. 



spec Set_OF_List [sort Elem] = 

Generated_Set [List_Selectors [sort Elem] fit Elem List] 

The above generic specification Set_OF_List describes sets of lists of ar- 
bitrary elements, and is obtained by an instantiation of the generic specifi- 
cation Generated_Set, whose parameter ‘sort Elem’ is instantiated by the 
specification List_Selectors, itself trivially instantiated. Since the (trivially 
instantiated) specification List_Selectors exports two sorts Elem and List, 
it is of course necessary to specify, in the instantiation of Generated_Set, 
the fitting symbol map from the parameter sort Elem to the argument sort 
List. 

Note especially that the following specification: 

spec Mistake [sort Elem] = 

Generated_Set [List_Selectors [sort Elem]] 

does not provide sets of lists of elements: The sort Elem in the parameter 
of Generated_Set is mapped by the identity fitting symbol map to the 
sort Elem provided by the instantiation of the generic specification List_ 
Selectors [sort Elem], rather than to the sort List.^ Thus Mistake just 
provides sets of arbitrary elements and lists of arbitrary elements. If this was 
indeed the desired effect, then one should rather write instead: 

spec Set_AND_List [sort Elem] = 

Generated_Set [sort Elem] and List_Selectors [sort Elem] 

As illustrated by Set_OF_List, composition of generic specifications is 
fairly easy in Case. Note however that this composition is achieved by means 
of appropriate instantiations (some possibly trivial), and that Case does not 
provide higher-order genericity. 

It may be worth mentioning that the following composition of generic 
specifications is ill-formed: 

spec ThisJs_Still_Wrong = 

GeneriC-Monoid [ GeneriC-Monoid [sort Elem] 
fit Elem I— > Monoid ] 

^ However, the situation would be different if the parameter of Generated_Set 
had been, e.g., ‘sort VaV, since then the absence of an explicit fitting symbol map 
would have led to an ambiguity: in that case the specifier would have to specify 
whether the sort Val is to be mapped to Elem or to List. 



7.2 Compound Symbols 



85 



The above instantiation is ill-formed since the sort Monoid and the operation 
symbols ‘7’ and are shared between the body of the generic specification 
GeneriC-Monoid and the argument specification Generic_Monoid [sort 
Elem] (where this time the generic specification Generic_Monoid is triv- 
ially instantiated). The next section provides (p. 86) a correct specification of 
monoids of monoids. 



7.2 Compound Symbols 



Compound sorts introduced by a generic specification get 
automatically renamed on instantiation, which avoids name clashes. 



spec List_Rev [sort Elem] = 

free type List[Elem] ::= empty \ 

cons{head :? Elem- tail :? List[Elem]) 
ops __H — h — : List[Elem] x List[Elem] — > List[Elem], 
assoc, unit empty, 
reverse : List[Elem] — > List[Elem] 

Ve : Elem; L,L1,L2 : List[Elem] 

• cons{e, LI) ++ L2 = cons{e, LI ++ L2) 

• reverse(empty) = empty 

• reverse{cons{e, L)) = reverse(L) -|--|- cons{e, empty) 

end 

spec List_Rev_Nat = ListJTev [Natural] 

A compound sort is a sort of the form ^Name\Namel , NameN]' . In the 
specification List_Rev, we introduce a compound sort List[Elem] to denote 
lists (of arbitrary elements), instead of the simple sort List used in the previous 
examples. When the specification List_Rev is instantiated as in List_Rev_ 
Nat, the translation induced by the (implicit) fitting symbol map is applied 
to the component Elem also where it occurs in List[Elem], providing a sort 
List[Nat]. Thus, compound sorts can be seen as a convenient way of implicitly 
completing the instantiation by an appropriate renaming of the (compound) 
sorts introduced by the generic specification. 

spec Two_Lists = 

LiST_ReV [Natural] %% Provides the sort List[Nat] 
and List_Rev [Golor fit Elem i— > RGB ] %% Provides the sort List[RGB] 

Using a compound sort List [Elem] proves particularly useful in the above 
example Two_Lists, where we make the union of two distinct instantiations 
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of List_Rev. If we had used an ordinary sort List, then an unintentional name 
clash would have arisen,^ and we would have to complete each instantiation 
by an explicit renaming of the sort List. 

Note that in the specification Two_Lists, we have two sorts List[Nat] and 
List[RGB], hence two overloaded constants empty (one of each sort), which 
may need disambiguation when used in terms. (How to disambiguate terms 
is explained in Chap. 3, p. 31.) 

Similarly, we have overloaded operation symbols cons, head, tail, H — h, 
and reverse, but in general their context of use in terms will be enough to 
disambiguate which one is meant. 

spec Two_Lists_1 = 

List_Rev [ Integer_Arithmetic_ 1 fit Elem i— > Nat ] 
and List_Rev [ Integer_Arithmetic_ 1 fit Elem i— > Lnt ] 

Since the specification Integer_Arithmetic_1 provides three sorts Nat, 
Pos, and Lnt, an explicit fitting symbol map is needed in the above instantia- 
tions, which provide the sorts List[Nat] and List[Lnt]. Note that the subsorting 
relation Nat < Lnt does not entail List[Nat] < List[Lnt], but of course this 
can be added if desired in an extension by a subsorting declaration. 

Using compound sorts, we can now easily specify monoids of monoids. 

spec Monoid_C [sort Elem] = 
sort Monoid[Elem] 
ops inj : Elem Monoid[Elem\', 

1 : Monoid[Elem\, 

Monoid[Elem] x Monoid[Elem] Monoid[Elem], 
assoc, unit 1 

Vz, y : Elem • inj{x) = inj{y) ^ x = y 

end 

spec Monoid_OF_Monoid [sort Elem] = 

Monoid_C [Monoid_C [sort Elem] fit Elem i— s- Monoid[Elem]] 

The instantiation in Monoid_OF_Monoid is now correct, since the use of a 
compound sort Monoid [Elem] ensures there is no clash of symbols between the 
body of the instantiated generic specification and the argument specification. 

^ And the specification Two_Lists would have been inconsistent, due to the same 
name, same thing principle and the fact that List is defined by a free type con- 
struct. 
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Compound symbols can also he used for operations and predicates. 



spec List_Rev .Order [Total.Order] = 

ListJIev [sort Elem] 

then local op insert : Elem x List[Elem] List[Elem] 

Ve, e' : Elem- L : List[Elem\ 

• insert{e, empty) = cons{e, empty) 

• ins ert(e, cons (e', L)) = cons(e', insert(e, L)) when e' < e 

else cons{e, cons{e' , L)) 

within op order [__ < __] : List[Elem] List[Elem] 

Ve : Elem' L : List[Elem\ 

• order [__ < _J\{empty) = empty 

• order[__ < __](cons(e, L)) = insert{e, order[__ < — ](L)) 

end 

spec List JIev_with_Two_Orders = 

List JLev .Order 

[Integer.Arithmetic.Order fit Elem Int, .. < _.] 

%% Provides the sort List[Int] and the operation order[__ < __] 
and List JLev.Order 

[Integer.Arithmetic.Order fit Elem i— > Int, eo- .. > _.] 

%% Provides the sort List[Int] and the operation order[__ > __] 

then %implies 

VL : List[Int] • order[_. < ..](L) = reverse{order[^_ > __](L)) 

end 

The above example illustrates the use of compound identifiers for operation 
symbols, and the same rules apply to predicate symbols. While in most cases 
using compound identifiers for sorts will be sufficient, in some situations it 
is also convenient to use them for operation or predicate symbols, as done 
here for order [.. < __]. When List JLev .Order is instantiated, not only does 
the sort List[Elem] get renamed (here, to List[Int]), but also the operation 
symbol order [_. < ..], according to the fitting symbol map corresponding to 
the instantiation. If we had not used a compound identifier for the order 
operation, then an unintentional name clash would have arisen. Note that on 
the other hand we rely on the same name, same thing principle to ensure that 
the sorts List[Int] provided by each of the two instantiations are the same, 
which indeed is what we want for this example. 

Of course we do not bother to use a compound identifier for the insert 
operation symbol. This operation being local, it is not exported by List. 
Rev.Order and cannot be the source of unintentional name clashes in in- 
stantiations. 
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7.3 Generic Specifications with Imports 



Parameters should be distinguished from references to fixed 
specifications that are not intended to he instantiated. 



spec List_Weighted_Elem [sort Elem op weight : Elem — > Nat] 
given Natural_Arithmetic = 

List_Rev [sort Elem] 
then op weight : List[Elem] — > Nat 
Ve : Elem; L : List[Elem] 

• weight{empty) = 0 

• weight(cons(e, L)) = weight (e) + weight (L) 

end 

In the above example, we specialize lists of arbitrary elements to lists 
of elements equipped with a weight operation, which is then overloaded by 
a weight operation on lists. Therefore we specify that the generic specifica- 
tion List_Weighted_Elem has for parameter a specification extending the 
‘given’ specification Natural_Arithmetic by a sort Elem and an operation 
symbol weight. Thereby the intention is to emphasize the fact that only the 
sort Elem and the operation weight are intended to be specialized when the 
specification List_Weighted_Elem is instantiated, and not the ‘fixed part’ 
Natural_Arithmetic. In Case, the specifications listed after the ‘given’ 
keyword are called imports. One could have written instead: 

spec List_Weighted_Elem 

[ Natural_Arithmetic then sort Elem op weight : Elem — > Nat] 



but the latter, which is correct, misses the essential distinction between the 
part which is intended to be specialized and the part which is ‘fixed’ (since, 
by definition, the parameter is the part which has to be specialized). 

Note also that omitting the ‘given Natural_Arithmetic’ clause would 
make the declaration: 

spec List_Weighted_Elem [sort Elem op weight : Elem — > Nat] = . . . 

ill-formed, since the sort Nat is not available. 

To summarize, the ‘given’ construct is useful to distinguish the ‘true’ 
parameter from the part which is ‘fixed’. Both the parameter and the body of 
the generic specification extend what is provided by the imports (i.e., by the 
specifications listed after the ‘given’ keyword), whose exported symbols are 
therefore available. 
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Argument specifications are always implicitly regarded as extension of 
the imports. 



spec List_Weighted_Pair_Natural_Color = 

List_Weighted_Elem [Pair_Natural_Color fit Elem Pair, 

weight i— > first ] 

The instantiation specified in LiST_WEiGHTED_PAiRj>fATURAL_COLOR is 
correct since the fitting symbol map is the identity on all the symbols exported 
by the ‘fixed part’ Natural_Arithmetic (which happens here to be included 
in the argument specification PairJN^ATURAL_Color). More generally, the 
argument specification is always regarded as an extension of the imports, and 
the fitting symbol map should be the identity on all symbols provided by these 
imports. This is illustrated in the next example: 

spec List_Weighted_Instantiated = 

List_Weighted_Elem [sort Value op weight : Value Nat] 

Here we rely on a rather trivial instantiation (whose purpose is merely 
to illustrate our point) where the fitting symbol map can be omitted since 
no ambiguity arises and where the argument specification ‘sort Value op 
weight : Value Nat' is well-formed because it is regarded as an extension 
of the imports of List_Weighted_Elem (i.e., as an extension of Natural. 
Arithmetic), which implies that the sort Nat is available. 

k 



Imports are also useful to prevent ill-formed instantiations. 



spec ListJjENGTH [sort Elem] given Natural.Arithmetic = 
ListJTev [sort Elem] 
then op length : List[Elem] Nat 
Ve : Elem; L : List[Elem] 

• length{empty) = 0 

• length(cons{e, L)) = length{L) 1 
then %implies 

VL : List[Elem] • length{reverse{L)) = length[L) 

end 

The specification List_Length needs the sort Nat and the usual arith- 
metic operations provided by NaturalAVrithmetic to specify the length 
operation. In this case it is clear that the imports have nothing to do with 
the (trivial) parameter of List_Length. The reason to specify Natural. 
Arithmetic as an import is that this will make instantiations of List. 
Length similar to the following one well-formed. 
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spec List_Length JN^atural = 

List_Length [Natural_Arithmetic] 

To understand this point, consider the following variant of List_Length: 

spec Wrong_List_Length [sort Elem] = 

Natural_Arithmetic and List_Rev [sort Elem] 
then . . . 
end 



The specification Wrong_List_Length is fine as long as one does not 
need to instantiate it with Natural_Arithmetic as argument specifica- 
tion. The instantiation Wrong_List_Length [Natural_Arithmetic] is 
ill-formed since some symbols of the argument specification are shared with 
some symbols of the body (and not already occurring in the parameter) of the 
instantiated generic specification, which is wrong, as already explained p. 80. 
Of course the same problem will occur with any argument specification which 
provides, e.g., the sort Nat. 



In generic specifications, auxiliary required specifications should be 
imported rather than extended. 



As illustrated by the above examples, one should remember the follow- 
ing essential point. Since an instantiation is ill- formed as soon as there are 
some shared symbols between the argument specification and the body of 
the generic specification, when designing a generic specification, it is gener- 
ally advisable to turn auxiliary required specifications (such as Natural. 
Arithmetic for List_Length) into imports, and generic specifications of 
the form [ A] = SP then . . . ’ are better written ‘A [ A ] given SP = . . . ’ 
to allow the instantiation ‘A [5P]’. 
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Views are named fitting maps, and can be defined along with 
specifications. 



view Integer.as_Total_Order : 

Total.Order to Integer_Arithmetic_Order = 
Elem I— !■ Int, __ 
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view Integer_as_Reverse_Total_Order : 

Total_Order to Integer_Arithmetic_Order = 

Elem I— > /nt, __ > __ 

spec List_Rev_with_Two_Orders_1 = 

List_Rev .Order [view Integer.as_Total_Order] 
and List JIev .Order [view Integer.as JLeverse.Total.Order] 

then %implies 

VL : List[Ini\ • orrfer[_. < ..](L) = reverse{order[_- > __](L)) 

end 

A view is nothing but a convenient way to name a specification morphism 
(induced by a symbol map) from a (parameter) specification to an (argument) 
specification. The rules regarding the omission of ‘evident’ symbol maps in 
explicit fittings apply to views too. A view proves particularly useful when 
the same instantiation (with the same fitting symbol map) is intended to be 
used several times: naming a specification morphism once and for all makes 
its reuse easier. Once a view is defined, as e.g. Integer.as.Total.Order 
above, it can be referenced in instantiations as in List JLev .Order [view 
Integer.AS.Total.Order], where the keyword ‘view’ makes it clear that 
the argument is not merely a named specification with an implicit fitting map, 
which would be written differently. 

Since a view is defined only when the given symbol map induces a spec- 
ification morphism (i.e., all models of the target specification, when reduced 
along the signature morphism induced by the given symbol map, provide 
models of the source specification), it may be convenient to use views just 
to explicitly document the existence of some specification morphisms, even 
when these are not intended to be used in any instantiation. For instance, the 
view Integer.as.Total.Order can be seen as the assertion that Integer. 
Arithmetic.Order indeed specifies ‘<’ to be a total ordering relation, and 
would therefore make sense even without being used later on in instantiations. 



Views can also he generic. 



view List.ASJV[ONOID [sort Elem] : 

Monoid to List.Rev [sort Elem] = 

Monoid i— > List[Elem], 1 empty, i— > .. + +.. 

A view can be generic, being then defined with some parameters (as il- 
lustrated above in the L1ST.AS.MONOID view) and possibly some imports. 
The reader should be aware that, in a generic view, the target specification 
(here, the trivially instantiated specification List.Rev) is not interpreted as 
such, but as the body of a generic specification with the same parameters and 
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imports as the view. (The source specification is on the contrary interpreted 
exactly as provided.) 

The above example illustrates again the use of a view as a ‘proof obliga- 
tion’, asserting that lists (equipped with the operation) form a monoid. 



8 



Specifying the Architecture of Implementations 



Architectural specifications impose structure on implementations, 
whereas specification-building operations only structure the text of 
specifications. 



As explained in the previous chapters, the specification of a complex sys- 
tem may be fairly large and should be structured into coherent, easy to grasp, 
pieces. Casl provides a number of specification-building operations to achieve 
this, as detailed in Chap. 6. Moreover, generic specifications, described in 
Chap. 7, provide pieces of specification that are easy to reuse in different 
contexts, where they can be adapted as desired by instantiating them. 

Specification-building operations and generic specifications are useful to 
structure the text of the specification of the system under consideration. How- 
ever, the models of a structured specification have no more structure than do 
those of a fiat, unstructured, specification. Indeed, most examples given in 
the previous chapters could have been structured differently, with the same 
meaning (i.e., with the same models). Structured specifications are usually ad- 
equate at the requirements stage, where the focus is on the expected overall 
properties of the system under consideration. 

In contrast, the aim of architectural specifications is to prescribe the in- 
tended architecture of the implementation of the system. Architectural speci- 
fications provide the means for specifying the various components from which 
the system will be built, and describing how these components are to be assem- 
bled to provide an implementation of the system of interest. At the same time, 
they allow the task of implementing a system to be split into independent, 
clearly-specified sub-tasks. Thus, architectural specifications are essential at 
the design stage, where the focus is on how to factor the implementation of 
the system into components. 

The aim of this chapter is to discuss and illustrate both the role of archi- 
tectural specifications and how to express them in Casl. 



M. Bidoit and P.D. Mosses: CASL User Manual, LNCS 2900, pp. 93-109, 2004. 
(c) IFIP International Federation for Information Processing 2004 
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The idea underlying architectural specifications is that eventually in the 
process of systematic development of modular software from specifications, 
components are implemented as software modules in some chosen program- 
ming language. However, this step is beyond the scope of specification for- 
malisms, so in Casl and in this chapter we identify components with models 
(and with functions from models to models, in the case of generic components) . 
The modular structure of the software under development, as described by an 
architectural specification, is therefore captured here simply as an explicit. 



structural way to build Casl models. 


L 


The examples in this chapter are artificially simple. 


[ 





Architectural specifications, and more generally component-oriented ap- 
proaches, are intended for relatively large systems. In this chapter, however, 
we have to rely on simple small examples to illustrate and explain Casl ar- 
chitectural specification concepts and constructs. After reading this chapter, 
the reader is encouraged to study Chap. 13, which provides realistic exam- 
ples of the use of architectural specifications. A more detailed account of the 
rationale behind architectural specifications in the context of formal software 
development by stepwise refinement can be found in [11]. 

The following structured specifications will be referred to later in this 
chapter when illustrating Casl architectural specifications: 

spec Color = %{ As defined in Chap. 3, p. 37 }% 

spec Natural_Order = %{ As defined in Chap. 3, p. 38 }% 

spec Natural_Arithmetic = %{ As defined in Chap. 3, p. 38 }% 

spec Elem = sort Elem 

spec CONT [Elem] = 

generated type Cont[Elem\ ::= empty \ insert{Elem] Cont[Elem\) 
preds -empty : Cont[Elem\] 

—is -in— : Elem x Cont[Elem] 
ops choose : Cont[Elem] Elem] 

delete : Elem x Cont[Elem\ Cont[Elem] 

Ve, e' : Elem; C : Cont[Elem] 

• empty is -empty 

• insert{e, C) is-cmpty 

• -I e is -in empty 

• e is-in insert{e' , C) (e = e' V e is-in C) 

• def choose(C) ^ C is-cmpty 

• def choose(C) ^ choose{C) is-in C 

• e is-in delete {e' , C) <t4> (e is-in C A “>(e = e')) 



end 
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spec Cont_Diff [Elem] = 

CoNT [Elem] 

then op dijf : Cont[Elem] x Cont[Elem] Cont[Elem] 

Ve : Elem; (7, C' : Cont[Elem] 

• e is-in C) (e is-in C A ~^{e is-in C')) 

end 

spec Req = ContJDiff [Natural_Order] 

spec Flat_Req = 

free type Nat ::= 0 \ suc(Nat) 
pred Nat x Nat 

generated type Cont[Nat] ::= empty \ insert{Nat; Cont[Nat]) 
preds -empty : Cont[Nat]; 

-is-iri— : Nat x Cont[Nat] 
ops ehoose : Cont[Nat] — >? Nat; 

delete : Nat x Cont[Nat] — > Cont[Nat]; 
dijf : Cont[Nat] x Cont[Nat] —>■ Cont[Nat] 

Ve, e' : Nat; C, C : Cont[Nai\ 

• 0 < suc{e) 

• ^(e < 0 ) 

• suc(e) < suc(e') e < e' 

• empty is -empty 

• ^ insert{e, C) is-empty 

• ^ e is -in empty 

• e is-in insert{ef C) (e = e' V e is-in C) 

• def choose(C) ^ C is-empty 

• def choose{C) choose{G) is-in C 

• e is-in delete {e' , C) (e is-in C A ->{e = e')) 

• e is -in dijf{C, C) (e is -in C A ^(e is -in C')) 

end 



8.1 Architectural Specifications 

Let’s assume in the following that Req describes our requirements about the 
system to be implemented. First, note that both Req and Flat_Req have 
the same models, which illustrates our point about the fact that the Case 
specification-building operations are merely facilities to structure the text of 
specifications into coherent units. 
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An architectural specification consists of a list of unit declarations, 
specifying the required components, and a result part, indicating how 
they are to he combined. 



arch spec System = 
units N : Natural_Order; 

C : CONT [Natural_Order] given N; 

D : Cont_Diff [Natural_Order] given C 
result D 

The System architectural specification is intended to prescribe a specific 
architecture for implementing the system specified by Req. 

The first part, introduced by the keyword units, indicates that we require 
the implementation of our system to be made of three components N , C , and 
D. The second part, introduced by the keyword result, indicates that the 
component D provides the desired implementation. 

Each component is provided with its specification. The line: 

N : Natural_Order 

declares a component N specified by Natural_Order, which means simply 
that N should be a model of Natural_Order. 

The line: 

C : CONT [Natural_Order] given N 

declares a component C which, given the previously declared component N , 
provides a model of CONT [Natural_Order]. It is essential to understand 
that the component C must expand the assumed component N into a model 
of CONT [ Natural_Order], which means that C reduced to the signature 
of Natural_Order must be equal to N . This property reflects the fact that 
a software module is supposed to use what it is given exactly as supplied, 
without altering it. 

Similarly, the line: 

D : Cont_Diff [Natural_Order] given C 

declares a component D which, given the component C , expands it into a 
model of ContJDiff [Natural_Order]. 

The final result is therefore simply D. (More complex examples of result 
expressions will be illustrated in examples below.) 

As in the rest of Case, visibility is linear in architectural specifications, 
meaning that any component must be declared before being used (e.g., the 
component N should be declared before being referred to by ‘given A’ in the 
declaration of the component C in the architectural specification System). 
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Component names (such as N, C, and D in System) are local to the ar- 
chitectural specification where they are declared, and are not visible outside 
it. 





There can he several distinct architectural choices for the same 
requirements specification. 



arch spec System_ 1 = 
units N : Natural_Order; 

CD : Cont_Diff [Natural_Order] given N 
result CD 

The architectural specifications System and System_1 both provide mod- 
els of Req. However, the former insists on an implementation made of three 
components, while the latter insists on an implementation made of two com- 
ponents. Thus the architectural specification System_1 corresponds to a dif- 
ferent architectural choice for implementing our Req specification. Of course, 
further design for implementing the component CD of System_1 may lead 
to splitting this implementation task exactly as in System above. However, 
there are also other possibilities, including for instance an architectural design 
where we would split the task of implementing CD into two different tasks, 
one for implementing containers with all their operations (including diff) ex- 
cept delete, the other for implementing delete by means of diff and other 



operations. 


L 


Each unit declaration listed in an architectural specification 
corresponds to a separate implementation task. 


[ 





For instance, in the architectural specification System, the task of provid- 
ing a component D expanding C and implementing Cont_Diff [Natural. 
Order] is independent from the tasks of providing implementations N of 
Natural.Order and C of Cont [Natural.Order] given N. Hence, 
when providing the component D, one cannot make any further assumption 
on how the component C is (or will be) implemented, besides what is expressly 
ensured by its specification. 

To understand this, let us consider again the requirements specification 
Req (or its variant FlatJTeq). Among its models, there is one where con- 
tainers are implemented by sorted lists (in increasing order, without repeti- 
tions), and in this model we can choose to implement diff by the following 
algorithm: 
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diff{L, L') = nil when L = nil 

else L when L' = nil 

else ins ert (head (L), diff {tail {L), L')) when head{L) < head(L') 
else diff (tail (L), tail (L')) when head(L) = head(L') 
else diff(L, tail(L')) 

In this model, however, we rely on knowledge about the implementation 
of containers to decide how to implement diff ~~ which is fine, since both 
are simultaneously implemented in the same component. In contrast, in the 
architectural specification System, we request that containers are to be im- 
plemented in the component C while diff is to be provided by a separate com- 
ponent D . Imposing that the component D can be developed independently of 
the component C means that for D it is no longer possible to implement diff 
as sketched above, since this specific implementation choice may not be com- 
patible with an independently chosen realization for C (where containers may 
be implemented by bags, for instance). Hence an implementation of diff in the 
component D can only rely on the operations provided by C (e.g., choose and 
delete)] this may turn out to be less efficient for some particular realization of 
C, but should be compatible with any independently chosen realization for C 
(bags, for instance). In the case of the architectural specification System_1, 
since both containers and the diff operation are implemented in the same 
component CD, we can of course decide to implement containers by ordered 
lists without repetitions and diff as sketched above. 

Thus the component D should expand any given implementation C of 
CONT [Natural_Order] and provide an implementation of ContJDiff 
[Natural_Order], which is tantamount to providing a generic implemen- 
tation G of ContJDiff [Natural_Order] which takes the particular im- 
plementation of CoNT [Natural_Order] as a parameter to be expanded. 
Then we obtain D by simply applying G to C . 

Genericity here arises from the independence of the developments of C 
and D, rather than from the desire to build multiple implementations of 
ContJDiff [ Natural_Order] using different implementations of Cont 
[Natural_Order]. This is reflected by the fact that G is left implicit in the 
architectural specification System. 



A unit can be implemented only if its specification is a conservative 
extension of the specifications of its given units. 


L 


[ 





For instance, the component D can exist only if the specification Cont_ 
Diff [Natural_Order] is a conservative extension of Cont [Natural. 
Order], i.e., if any model of the latter specification can be expanded into a 
model of the former one, which is indeed the case here. Similarly, the compo- 
nent C can exist since Cont [Natural.Order] is a conservative extension 
of Natural.Order. 
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Consider now the following variant of ContJDiff [Natural_Order] 
and the associated variant of the architectural specification System. 

spec Cont_Diff_1 = 

CoNT [Natural_Order] 
then op diff : Cont[Nat] x Cont[Nat] Cont[Nat] 

\/x, y : Nat] C, C : Cont[Nat] 

• diff {C , empty) = C 

• diff (empty, C) = empty 

• diff (insert (x, C), insert (y, C')) = 

insert(x,diff (C, insert (y, C'))) when x < y 
else diff(C, C) when x = y 
else diff (insert (x , C), C) 

• X is-in diff(C, C) (2; is-in C A ~^(x isJn C')) 

end 

arch spec Inconsistent = 
units N : Natural_Order; 

C : CONT [Natural_Order] given N] 

D : Cont_Diff_1 given C 
result D 

The specification Cont_Diff_1 is consistent (has some models, for in- 
stance sorted lists, in increasing order, without repetitions), but is not a con- 
servative extension of CONT [ Natural_Order] (since, for instance, a model 
of CONT [Natural_Order] where containers are realized by arbitrary lists, 
possibly with repetitions, cannot be expanded into a model of Cont_Diff_1 
- in that case, the last two axioms are contradictory). As a consequence, in the 
architectural specification Inconsistent, the specification of the component 
D is inconsistent, since no component can expand all implementations C of 
CONT [Natural_Order] into models of Cont_Diff_1. The architectural 
specification Inconsistent is therefore itself inconsistent. 

To summarize, architectural specifications not only prescribe the intended 
architecture of the implementation of the system, but they also ensure that 
the specified components can be developed independently of each other (which 
imposes a certain degree of genericity for these components). 
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8.2 Generic Components 



Genericity of components can be made explicit in architectural 
specifications. 



arch spec System_G = 
units N : Natural_Order; 

F : Natural_Order ^ Cont [Natural_Order]; 

G : Cont [Natural_Order] ^ ContJDiff [Natural_Order] 
result G [A^]] 

The architectural specification System_G is a variant of System; here 
we choose to specify the second and third components as explicit generic 
components. 

The line: 

F : Natural_Order ^ Cont [Natural_Order] 

declares a generic component F. Given any component implementing (i.e., 
model of) Natural_Order, F should expand it into an implementation of 
Cont [Natural_Order]. The models of the generic-component specifica- 
tion Natural_Order — > Cont [Natural_Order] are functions that map 
any model of Natural_Order to a model of Cont [Natural_Order]. 
These functions are required to be persistent, meaning that the result model 
expands the argument model. 

The third component G is also specified as a generic component: given 
any implementation of CONT [Natural_Order], G should expand it into 
an implementation of Cont_Diff [Natural_Order]. 

Hence the whole system is obtained by the composition of applications 
G [F [A^]], as described in the result part. In Case, such combinations of com- 
ponents are called unit terms. (More complex examples of unit terms will be 
illustrated in examples below.) 

The component G of System corresponds to the application T [A^] in 
System_G, and similarly the component D in System corresponds to G [G], 
i.e., to G [T [N]] in System.G. 

The models of a specification of the form SPl SP2 are generic com- 
ponents GG that should always expand their argument into a model of the 
target specification. This only makes sense as long as the signature of the tar- 
get specification contains the signature of SPl . This is why in Case, SP2 is 
always considered as an implicit extension of SPl , and SPl — > SP2 abbrevi- 
ates SPl — > { SPl then SP2 }.^ Moreover, since the generic component GG 



^ When SP2 is already defined as an extension of SPl , as it is the case for instance 
here for Cont_Diff [Naturae_Order], SP2 is equivalent to SPl then SP2. 
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should expand any model of SPl , the specification SPl SP2 is consistent 
(i.e., has some models) if and only if the specification SPl then SP2 is a 
conservative extension of SPl . Forgetting this fact is a potential source of in- 
consistent specifications of generic components in architectural specifications. 
For instance, the specification CONT [Natural_Order] — > Cont_Diff_1 is 
inconsistent, for the reasons explained at the end of the previous section. 



A generic component may be applied to an argument richer than 
required by its specification. 



arch spec Systfm_A = 

units NA : Natural_Arithmftic; 

F : Natural_Ordfr ^ CoNT [Natural_Ordfr]; 

G : CoNT [Natural_Ordfr] — > Cont_Diff [Natural_Ordfr] 
result G [F [AfA]] 

The above architectural specification Systfm_A is a variant of Sys- 
tfm_G. Here we require a component NA implementing the specification 
Natural_Arithmftic, instead of a component N implementing Natural. 
Order as in System.G (perhaps because we know that such a component is 
already available in some collection of previously-implemented components.) 

The generic component F requires a component fulfilling the specification 
Natural.Order, but can of course be applied to a richer argument, as in 
F [AA]. A similar reasoning applies to G. 

More generally, a generic component can be applied to any component (or 
to any unit term) that can be reduced along some morphism to an argument 
of the required ‘type’ (i.e., to a model of the required specification). When 
necessary, a fitting symbol map can be used to describe the correspondence 
between the symbols provided by the argument and those expected by the 
generic component. We do not detail here the technicalities related to these 
fitting symbol maps, since they are quite similar to those used in instantiations 
of generic specifications and the notations are the same. 

As a last remark, note that, similarly to what happens when instantiating a 
generic specification by an argument specification, when a generic component 
is applied to an argument richer than required, the extra symbols are kept in 
the result. Hence the result of the architectural specification SystemAV above 
contains also the interpretations of the arithmetic and ordering operations on 
natural numbers, as they are provided by the component NA. This means in 
particular that the implementations described by SystemAV have a larger 
signature than the ones described by System.G. 
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V, 



Specifications of components can be named for further reuse. 



unit spec Cont_Comp = Elem ^ Cont [Elem] 

unit spec Diff_Comp = Cont [Elem] ^ Cont_Diff [Elem] 

arch spec System_G 1 = 
units N : Natural_Order; 

F : CONT_COMP; 

G : Diff_Comp 
result G [E [A]] 

In the above example, we give the name Cont_Comp to the specification 
(of generic components) Elem — > CONT [Elem]. Similarly, we give the name 
Diff_Comp to the specification Cont [Elem] — > ContJDiff [Elem]. Then 
both named specifications can be reused in the architectural specification 
System_G1 which is similar to the architectural specification System_G. 

In the architectural specification System_G1, we use again the fact that 
the generic component F can be applied to richer arguments than models 
of Elem (and similarly for G). Since Elem is more general (has more mod- 
els) than Natural_Order, there are potentially fewer possibilities for im- 
plementing the generic component specified by Cont_Comp (which should 
be compatible with any model of Elem) than there are for implementing 
the generic component specified by Natural_Order ^ CONT [Natural. 
Order] (which only needs to be compatible with models of Natural. 
Order; a similar argument holds for Diff.Comp). As a consequence, the 
architectural specifications System.G and System.GI do not describe the 
same implementations of the requirements specification Req. 



Both named and unnamed specifications can be used to specify 
components. 



unit spec Diff.Comp.1 = 

Cont [Elem] —> { op diff : Cont[Elem] x Cont[Elem] — > Cont[Elem] 
Ve : Elem; G, C' : Cont[Elem] 

• e is -in diff{C, C') 

(e is-in C A ^(e is-in C')) } 

So far we have always used named (structured) specifications to specify 
components, unnamed specifications can be used as well, as illustrated by 
the above variant Diff.Comp.1 of Diff.Comp. Here, for the sake of the 
example, we directly specify the diff operation instead of referring to the 
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named specification Cont_Diff. Remember that in a specification of a generic 
component of the form SPl — > SP2 , SP2 is always considered as an implicit 
extension of SPl , which explains why the above example is well-formed. 




Specifications of generic components should not be confused with 
generic specifications. 



Generic specifications naturally give rise to specifications of generic com- 
ponents, which can be named for later reuse, as illustrated above by Cont_ 
Comp. However, the reader should not confuse a generic specification (which 
is nothing other than a piece of specification that can easily be adapted by 
instantiation) with the corresponding specification of a generic component: 
the latter cannot be instantiated, it is the specified generic component which 
gets applied to suitable components. 

Conservative extensions of the form ‘spec SP2 = SPl then SP’ also 
naturally give rise to specifications of generic components of the form SPl 
SP2, as illustrated by Diff_Comp above. 



A generic component may he applied more than once in the same 
architectural specification. 



arch spec Other_System = 

units N : Natural_Order; 

C : Color; 

F : CONT_COMP 

result F [IV] and F [C fit Elem i— s- RGB] 

The above architectural specification requires a component N specified 
by Natural_Order, a component C specified by Color, and a generic 
component F specified by Cont_Comp. Then, as described by the result 
part, the desired system is obtained by applying F to N and applying F to C 
(in this case, an explicit fitting symbol map is necessary, since Color exports 
two sorts RGB and GMYK). Finally both application results are combined, 
which is expressed by ‘and’. 

Apart from ‘free’, all specification-building operations for structured 
specifications have natural counterparts at the level of components, which 
are expressed using the same keywords.^ The reader should remember that 
specification-building operations work with specifications defining classes of 

^ The situation is however a bit different with specification extensions, which lead 
to specifications of generic components, as explained above, or to specifications of 
components expanding a given component, as illustrated in the previous section. 
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models (e.g., union of specifications, denoted by ‘and’), while in architectural 
specifications we work with individual models (corresponding to components, 
as is the case here in Other_System where ‘and’ is used to combine the two 
components F [A] and f [C fit Elem i— > RGB ] ). 

Hence renaming and hiding also have natural counterparts at the level of 
components. For instance, remember that the implementations described by 
System_A have a larger signature than the implementations described by 
System_G. It is however easy to modify the result part of System_A if what 
we really want are implementations with the same signature as the imple- 
mentations described by System_G: one has just to hide the extra symbols 
resulting from the component NA as follows: 

result G [F [NA]] hide 1, 

or: 

result G [F [NA hide 1 , __ * __]] 

Symbol maps used in renaming and hiding at the level of components 
follow the same rules as symbol maps used in renaming and hiding at the 
level of structured specifications (see Chap. 6). 



Several applications of the same generic component is different from 
applications of several generic components with similar specifications. 



arch spec Other_System_1 = 
units N : Natural_Order; 

G : Color; 

FN : Natural_Order — > Cont [Natural_Order]; 

FG : Color ^ Cont [Color fit Elem RGB] 
result FN [A] and FG [G] 

The above architectural specification Other_System_1 is a variant of 
Other_System. However, in Other_System, we insist on choosing one im- 
plementation for containers in the generic component F , and then we apply it 
twice, first to a component N implementing Natural_Order, and then to 
a component G implementing Color. In contrast, in Other_System_1, we 
may choose two different implementations for containers, one for containers 
of natural numbers in the component FN and another one for containers of 
colors in the component FG . 

The architectural specifications Other_System and Other_System_1 
are therefore similar but clearly different. Neither is better than the other: 
each corresponds to a different architectural decision, and selecting one rather 
than the other is a matter of architectural design. Components that are more 
widely reusable tend to have less efficient implementations, in general. (Here 
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the fact that RGB has only three values might be exploited in FC to give a 
more space-efficient representation of containers than is possible for FN .) 



Generic components may have more than one argument. 


L 


[ 





unit spec Set_Comp = Elem — > Generated_Set [Elem] 

spec Cont2Set [Elem] = 

CONT [Elem] and Generated_Set [Elem] 
then op elements -of— : Cont[Elem] — > Set 

Ve : Elem; C : Cont[Elem\ 

• elements-of empty = empty 

• elements-of insert{e, C) = {e} U elements-of G 

end 

arch spec Arch_Gont2SetJMat = 
units N : Natural_Order; 

G : Gont_Gomp; 

S : Set.Gomp; 

E : Gont [Elem] x Generated_Set [Elem] 

^ Gont2Set [Elem] 
result E [G [A]] [S [A]] 

The architectural specification Arch_Gont2Set_Nat requires a compo- 
nent N implementing Natural_Order, a generic component G implement- 
ing Gont_Gomp, i.e., containers, and a generic component S implementing 
Set_Gomp, i.e., sets. Then it further requires a generic component F that, 
given any pair of compatible models X of Gont [ Elem ] and Y of Gener- 
ated_Set [Elem], expands them into a model of Gont2Set [Elem]. 

Models X and Y are said to be compatible if they share a common interpre- 
tation for all symbols they have in common. Here the only symbol they have 
in common is the sort Elem, so the compatibility condition means that X and 
Y have the same carrier set for Elem. Compatibility is a natural condition, 
since it is obviously necessary that X and Y have a common interpretation of 
their common symbols, otherwise they cannot be both expanded to the same 
more complex component. 

The result is then produced by applying F to the pair obtained by applying 
C to A and S to N . Here the pair of arguments G [A] and S [A] are obviously 
compatible, since their common symbols (the sort Nat equipped with the 
operations 0 and sue) all come from the same component A which provides 
their interpretation, which is expanded (hence cannot be modified) in C [A] 
and in S [A], thus compatibility is guaranteed. 
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Open systems can be described by architectural specifications using 
generic unit expressions in the result part. 



arch spec Arch_Cont2Set = 
units C : Cont_Comp; 

S : Set.Comp; 

F : CONT [Elem] X Generated_Set [Elem] 

^ Cont2Set [Elem] 
result A A : Elem • F [C [X]] [S' [A]] 

arch spec Arch_Cont2Set_Used = 
units N : Natural_Order; 

CSF : arch spec Arch_Cont2Set 
result CSF [A] 

So far our example architectural specifications have described ‘closed’, 
stand-alone systems where all components necessary to build the desired sys- 
tem were declared in the architectural specification of interest. In Casl, it is 
however possible to describe ‘open’ systems, i.e., systems made of some com- 
ponents that would require further components to provide a ‘closed’ system. 
This is illustrated by the architectural specification Arch_Cont2Set which 
describes a system with a generic component C implementing containers, a 
generic component S implementing sets, and a generic component F that ex- 
pands them to provide an implementation of the operation elements -of. The 
result part is therefore a generic structured component, i.e., an ‘open’ system, 
which, given any component A implementing Elem, provides a system built 
by applying F to the pair made of the applications of G to A and of 5” to A . 
In Casl, ‘A’ is input as ‘lambda’. 

As illustrated by Arch_Cont2Set_Used, we can then describe a ‘closed’ 
system made of a component N implementing Natural_Order, and of an 
‘open’ system CSF specified by Arch_Cont2Set, which is then applied to 
N in the result part. 



8.3 Writing Meaningful Architectural Specifications 

In the previous sections we have already pointed out potential sources of in- 
consistent specifications of components. Another issue which deserves some 
attention when designing an architectural specification is compatibility be- 
tween components (or, more generally, unit terms) that are to be combined 
together, either by ‘and’, or by fitting them to a generic component with 
multiple arguments. 
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When eomponents are to he eombined, it is best to eheek that any 
shared symbol originates from the same non-generie eomponent. 


L 


[ 





arch spec Arch_Cont2SetJ>Jat_ 1 = 
units N : Natural_Order; 

C : CONT_COMP; 

S : Set.Comp; 

G : { CONT [Elem] and Generated_Set [Elem] } 

^ Cont2Set [Elem] 

result G [C [N] and S [N] fit Gont[Elem] Gont[Nat]] 

The architectural specification Arch_Cont2Set_Nat_1 is a variant of 
Arch_Cont2Set_Nat where, instead of declaring a generic component F 
with two arguments, we now declare a generic component G with a single 
argument, which must be a model of the specification { CONT [ Elem ] and 
Generated_Set [Elem] }, obtained as the union of the two (trivially in- 
stantiated) specifications of containers and sets. 

As a consequence, to obtain the desired system, in the result part we apply 
the generic component G to the combination (denoted by ‘and’) of G applied 
to N and of S applied to N.^ This combination makes sense only if both G [A] 
and S [A] share the same interpretation of their common symbols. Here their 
common symbols (the sort Nat equipped with the operations 0 and sue) 
all come from the same component A which provides their interpretation, 
which is expanded (hence cannot be modified) in G [A] and in iS” [A], thus 
compatibility is guaranteed. 

There is a clear analogy here between the application of the generic com- 
ponent F with multiple arguments in Arch_Gont2Set_Nat and the com- 
bination of G [A] and S [N] in ARCH_GONT2SETj>fAT_l: in both cases the 
result is meaningful because we can trace shared symbols like the sort Nat 
and the operations 0 and sue to a single component A introducing them. 

Let us emphasize again that compatibility is a natural requirement: since 
each unit declaration corresponds to a separate implementation task (and 
hence each unit subterm to an independently developed subsystem) , obviously 
the combination of components or unit terms makes sense only when some 
compatibility conditions are fulfilled. 

Let us now consider an example where the compatibility condition is vio- 
lated. 

® In the application of the generic component G we need an explicit fitting symbol 

map since otherwise the sort Cont[Elem] can ambiguously be mapped to either 

Cont[Nat] or Set. 
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arch spec Wrong_Arch_Spec = 
units CN : CONT [ Natural_Order]; 

SN : Generated_Set [Natural_Order]; 

F : CoNT [Elem] X Generated_Set [Elem] 

^ Gont2Set [Elem] 

result F [CN] [^A] 

The architectural specification Wrong_Arch_Spec is a variant of Arch_ 
GONT2SETj>fAT where, instead of requiring a component N implementing 
Natural_Order and two generic components implementing containers and 
sets respectively, we just require a component CN implementing containers of 
natural numbers and a component SN implementing sets of natural numbers. 
However, then the application F [CN] [^A] makes no sense since there is 
no way to ensure that the common symbols of CN and SN have the same 
interpretation. It may indeed be the case that natural numbers are interpreted 
in some way in CN and in a different way in SN , which makes the application 
of F impossible. (Hence a similar problem would arise if one would use the 
combination of components ‘CN and SN’.) 

Let us now consider a more complex example. 



arch spec Badly _Structured_Arch_Spec = 
units N : Natural_Order; 

A : Natural_Order — > Natural_Arithmetic; 
C : Gont_Gomp; 

S : Set.Gomp; 

F : Gont [Elem] x Generated_Set [Elem] 

^ Gont2Set [Elem] 
result F [C [A [A]]] [S [A [A]]] 



The architectural specification Badly_Structured_Arch_Spec is a vari- 
ant of Arch_Gont2Set_Nat where, in addition to the component A imple- 
menting Natural_Order, we require a generic component A which is used 
to expand A into an implementation of Natural_Arithmetic. In the archi- 
tectural specification Arch_Gont2Set_Nat, the compatibility condition in 
the application F [C [A]] [5 [A]] was easy to discharge. Here, in the result unit 
term F [C [A [A]]] [5 [A [A]]] of Badly_Structured_Arch_Spec, we apply 
F to the pair made of G [A [A]] and 5 [A [A]]. In this case only a semantic 
analysis can ensure that these two arguments are compatible, since the com- 
mon symbols cannot be traced to the same non-generic component, but only 
to two applications of the same generic component A to similar arguments. 
(Actually the arguments are just the same here, but in general checking this 
would require non-trivial semantic reasoning.) 



It is advisable to use unit terms where compatibility can be checked by 
a simple static analysis. Casl provides additional constructs which make it 
easy to follow this recommendation, as explained below. 
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Auxiliary unit definitions or local unit definitions may be used to 
avoid repetition of generic unit applications. 



arch spec Well_Structured_Arch_Spec = 
units N : Natural_Order; 

A : Natural_Order — > Natural_Arithmetic; 

AN = A[A]; 

C : CONT_COMP; 

S : Set.Comp; 

F : CONT [Elem] X Generated_Set [Elem] 

^ Cont2Set [Elem] 
result F [C [AIV]] [S [AIV]] 

arch spec Another_Well_Structured_Arch_Spec = 
units N : Natural_Order; 

A : Natural_Order — > Natural_Arithmetic; 

C : CONT_COMP; 

S : Set.Comp; 

F : CoNT [Elem] x Generated_Set [Elem] 

^ Gont2Set [Elem] 

result local AN = A [A] within F [C [AA]] [S [AA]] 

The problem illustrated in Badly_Structured_Arch_Spec can be fixed 
easily. An auxiliary unit definition may be used to avoid the repetition of 
generic unit applications, such as ‘AA = A [A]’ in Well_Structured_ 
Arch_Spec. An alternative is to make the definition of AN local to the result 
unit term, as illustrated in Another_Well_Structured_Arch_Spec. In 
both cases common symbols can be traced to a non-generic unit, and com- 
patibility can be checked by an easy static analysis. 
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V, 



Libraries are named collections of named specifications. 



In the foregoing chapters, we have seen many examples of named specifica- 
tions, and of references to them in later specifications. This chapter explains 
how a collection of named specifications can itself be named, as a library. The 
creation of libraries facilitates the reuse of specifications. For practical appli- 
cations, it is important to be able to reuse (at least) existing specifications of 
basic datatypes, such as those described in Chap. 12. 

1-, 



Local libraries are self-contained. 



A library is called local when it is self-contained, i.e., for each reference to a 
specification name in the library, the library includes a specification with that 
name. Local libraries might appear at first sight to be all that we need, but 
actually they provide poor support for reuse of specifications. The problem 
is that when a specification from one local library is reused in another, it 
has to be repeated verbatim. There is no formal link between the original 
specification and the copy, despite them having the same name: the names 
used in a library can be chosen freely, and different libraries could use the 



same name for completely different specifications. 


L 


Distributed libraries support reuse. 


[ 





Distributed libraries allow duplication of specifications to be avoided al- 
together. Instead of making an explicit copy of a named specification from 



M. Bidoit and P.D. Mosses: CASL User Manual, LNCS 2900, pp. 111—122, 2004. 
@ IFIP International Federation for Information Processing 2004 



112 



9 Libraries 



one library for use in another, the second library merely indicates that the 
specification concerned can be downloaded from the first one. 



Different versions of the same library are distinguished by 
hierarchical version numbers. 



In practice, specifications evolve, e.g., to provide further operations or 
predicates on the specified sorts, or to define new subsorts. The libraries 
containing the specifications can evolve too, by adding or removing named 
specifications. Without some form of version control, even a trifling change in 
one library might cause specifications in other libraries to become ill-formed, 
or affect their meanings. Casl allows different versions of the same library 
to coexist (distinguishing them by hierarchical version numbers), and allows 
downloadings in a library to indicate that a particular version of another 
library is required. 



Creation of new libraries is essential in connection with larger specification 
projects, and projects of any scale can benefit from reuse of specifications 
from existing libraries. The rest of this chapter illustrates the constructs used 
to specify local libraries, distributed libraries, and versions, and gives some 
advice on the organization of libraries. 



9.1 Local Libraries 



V, 



Local libraries are self-contained collections of specifications. 



library UserManual/Examples 
spec Natural = . . . 

spec Natural_Order = Natural then . . . 

The collection of all the illustrative examples given in the foregoing chap- 
ters is self-contained, so it could be made into a local library and named User- 
Manual/Examples, as outlined above. To provide a separate local library 
for each chapter would however involve a considerable amount of duplication, 
since many of the specifications that are defined in the earlier chapters are 
also referenced in later chapters (e.g., Set_Partial_Choose in Chap. 4 in- 
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stantiates Generated_Set, which is defined in Chap. 3). Using distributed 
libraries, as explained in Sect. 9.2, this duplication can be avoided.^ 

The ‘same name, same thing’ principle of Case applies only within specifi- 
cations, and it is possible for a library to include alternative specifications for 
the same symbols (e.g., using different sets of axioms). However, when such 
alternative specifications are both extended (perhaps indirectly) in the same 
specification, the principle does apply, and unintended name clashes might 
then arise. Thus in general, it is advisable for the developers of a library to 
respect the ‘same name, same thing’ principle when choosing symbols through- 
out the library. In any case, this is obviously helpful to those who might later 
browse the library. Alternative specifications for the same symbols should 



therefore be given in separate libraries.^ 




Specifications can refer to previous items in the same library. 


L 
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library UserManual/Examples 



spec Strict _Partial_Order = . . . 

spec Total_Order = Strict_Partial_Order then . . . 

spec Partial_Order = Strict_Partial_Order then . . . 

Although we may often regard libraries as sets of named specifications, 
they are actually sequences^ and the order in which the specifications occur is 
significant. 

Specification names have linear visibility: each specification can refer only 
to the names of the specifications that precede it. Thus a series of extensions 
has to be presented in a bottom-up fashion, starting with a specification that 
is entirely self-contained, containing no references to other specifications at 
all. Each specification name in a library has a unique defining occurrence, so 
overriding cannot arise. Extensions that do not refer to each other may be 
given in any order (e.g., Partial_Order above could just as well be given 
before Total_Order). 

Linear visibility of specification names means that mutual recursion be- 
tween specifications is prohibited. When two specifications each make use of 
symbols declared in the other, the declarations of those symbols have to be 
duplicated, or moved to a preceding specification that can then be referenced 
by them both. 

^ A distributed library for each chapter of Part II is available via the CoFI web 
pages; copies are provided on the CD-ROM accompanying this book. 

^ If we intended our comprehensive UserManual/Examples library for general 
use, we would remove all the illustrative alternative specifications. 
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V, 



All kinds of named specifications can be included in libraries. 



library UserManual/Examples 
spec Strict _Partial_Order = . . . 
spec GeneriC-Monoid [sort Elem] = . . . 
view Integer_AS_Total_Order : . . . 
view List_as_Monoid [sort Elem] : 
arch spec System = . . . 
unit spec Cont_Comp = . . . 

Items in libraries can be any kind of named specification, as illustrated 
above: simple named specifications, generic specifications, named view defini- 
tions, generic view definitions, and architectural and unit specifications. We 
shall henceforth refer to them generally as library items. 

Libraries themselves never include anonymous specifications, such as dec- 
larations of sorts and operations. Moreover, the symbols declared by a library 
item are not automatically available for use in subsequent items: an explicit 
reference to the name of the library item is required to ‘import’ the item. 

Technically, each library item is said to be closed, being interpreted with- 
out any pre-declared symbols at all. This facilitates downloading items from 
distributed libraries, see Sect. 9.2. 



Display, parsing, and literal syntax annotations apply to entire 
libraries. 



library UserManual/Examples 

%display %LATEX __ < __ 

%display %LATEX __ > __ 

Redisplay __union__ %LATEX __U __ 

%prec < {__* 

%left_assoc __ * __ 

spec Strict _Partial_Order = . . . 
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spec Partial_Order = Strict_Partial_Order then 
spec Generated_Set [sort Elem] = . . . U. . . 
spec Integer_Arithmetic_Order = 

Annotations affecting the way terms are written or displayed apply to an 
entire library, and have to be collected at the beginning of the library. These 
annotations include display and precedence annotations, illustrated above. 

Recall that various reserved words and symbols in Case specifications are 
input in ASCII, but displayed as mathematical signs (e.g., universal quantifi- 
cation is input as ‘f orall’, and displayed as ‘V’ when this sign is available in 
the current display format) . Display annotations provide analogous flexibility 
for declared symbols. For example, the display annotations illustrated above 
determine how infix symbols input as ‘<=’, ‘>=’, and ‘union’ are displayed 
when using IAT[;;]X to format the specification. Note that a display annotation 
applies to all occurrences of the input symbol in the library, regardless of 
overloading. 

Display annotations can give alternative displays for different formats: 
apart from DTgX, both RTF and HTML are presently supported. The display 
of the annotation itself shows only the input syntax of the symbol and the 
result produced by the current formatter. The input form of one of the above 
annotations might be as follows: 

7odisplay union °/oHTML <sup>U</sup> 7,LATEX \cup 

When no display annotation is given for a particular format, the input format 
itself is displayed. Thus the symbol displayed as ‘U’ in the present DTeX 
version of this User Manual would be displayed as ^union' in an RTF version, 
unless the above annotation were to be extended with an RTF part. 

Parsing annotations allow omission of grouping parentheses when terms 
are input. A single annotation can indicate the relative precedence or the 
associativity (left or right) of a group of operation symbols. The precedence 
annotation for infix arithmetic operations given above, namely: 

%prec < {_ * __} 

allows a term such as a -I- (& * c) to be input (and hence also displayed) as 
a -I- & * c. The left-associativity annotation for -|- and *: 

%left_assoc 

allows (a -|- 6) -|- c to be input as a -|- 6 -|- c, and similarly for *; but the 
parentheses cannot be omitted in (a -|- &) — c (not even if were to be 

included in the same left-associativity annotation). 
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When an operation symbol is declared with the associativity attribute 
assoc, an associativity annotation for that symbol is provided automatically.^ 
Thus in practice, explicit associativity annotations are needed only for non- 
associative operations such as subtraction and division. 




Libraries and library items can have author and date annotations. 



library UserManual/Examples 

%authors( Michel Bidoit <bidoit@lsv.ens-cachan.fr>, 

Peter D. Mosses <pdmosses@brics .dk> )% 

%dates 15 Oct 2003, 1 Apr 2000 

spec Strict _Partial_Order = . . . 

%authors Michel Bidoit <bidoit@lsv. ens-cachan.fr> 

%dates 10 July 2003 

spec Integer_Arithmetic_Order = 

An author annotation at the beginning of a library indicates the collec- 
tive authorship of the entire library; one preceding an individual library item 
indicates its specific authorship. 

A date annotation at the beginning of a library should indicate the release 
date of the current version of the library. It may also give the release dates of 
some previous major versions, possibly including that of the original version. 
A date annotation on an individual library item should indicate when that 
item was last changed, and (optionally) the dates of previous changes. 

9.2 Distributed Libraries 



Libraries can he installed on the Internet for remote access. 


L 
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library Basic/Numbers 



%left_assoc 

%number 

%floating __A__ 

%prec {_A__} < 

® This implicit parsing annotation is local to the enclosing specification and to 
specifications that reference it, in contrast to ordinary parsing annotations. 
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spec Nat = 

free type Nat ::= 0 \ suc(Nat) 

ops 1 : Nat = suc{0); . . . ; 9 : Nat = suc{8); 

n : Nat) : Nat = (m * suc{9)) + n 

spec Int = Nat then . . . 
spec Rat = Int then . . . 
spec DecimalFraction = Rat then 

ops : Nat x Nat — > Rat; 

__F__ : Rat x Int Rat 

The above example is an extract from one of the Cast libraries of basic 
datatypes, described in Chap. 12 and available on the Internet. It illustrates 
the overall structure of a library intended for general use, as well as some 
helpful annotations concerning literal syntax for numbers, which are explained 
below. 



Validated libraries can he registered for public access. 


L 


[ 





CoFI will maintain a register of useful libraries. Registered Cast libraries 
are identified by hierarchical path names. For instance, all the Case libraries of 
basic datatypes have names starting with ‘Basic/’, and path names starting 
with ‘Case/’ are reserved for libraries connected with the Case language itself 
(e.g., the specification of the abstract syntax of Case in Case). 

Registered libraries will be mirrored at several sites, to ensure their con- 
tinuous accessibility. The URLs of a library can be obtained from the library 
name using a table provided on the CoFI web pages. 

Libraries have to be validated before registration. The validation of a li- 
brary ensures not only that it is well-formed, but also that semantic annota- 
tions expressing consistency of specifications (or conservativity over the pa- 
rameters, in case of generic or unit specifications) have been added, and that 
all proof obligations (corresponding both to well-formedness conditions and 
to semantic annotations in the library) have been verified. 

It is likely that new versions of existing libraries will be produced, e.g., 
providing further operations whose usefulness was not realized beforehand. 
Although the assignment and use of library version numbers allows users to 
protect their specifications from changes due to new versions (see Sect. 9.3), at 
least the names used in a registered library should not change much between 



versions. 
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V, 



Libraries should include appropriate annotations. 



In particular, parsing and display annotations can be provided, as ex- 
plained in Sect. 9.1. The above example illustrates a further kind of anno- 
tation, used to provide literal syntax for numbers in Casl. The effect of the 
illustrated annotations is that, after downloading the appropriate specifica- 
tions from the library Basic/Numbers, conventional decimal notation can 
be used for integers and decimal fractions, e.g., 4^, 2.718, lOE—12. The digits 
42 are interpreted as the term and 2.718 is interpreted as the term 

2::\718 (where 718 is subsequently interpreted as (7@@f The defini- 
tion of the operation is shown above; those of and are a bit 

more involved, and omitted here. Notice that the library Basic/Numbers is 
not hard-wired into Case, and users could provide annotations to interpret 
the literal syntax for integers and decimal fractions as terms involving different 
operations, e.g., on different sorts. 



Libraries can include items downloaded from other libraries. 



library Basic/ StructuredDatatypes 
from Basic/Numbers get Nat, Int 
spec List [sort Elem] given Nat = . . . 
spec Array . . . given Int = . . . 

Individual specifications and other items can be downloaded from other 
libraries. For example, the library Basic/StructuredDatatypes, outlined 
above, does not itself provide the specifications of natural numbers and in- 
tegers that are needed in the specifications List and Array, but instead 
downloads Nat and Int from the Basic/Numbers library. 

The names of the items to be downloaded from a library have to be listed 
explicitly: one cannot request the downloading of all the items that happen to 
be provided by a library. However, although the name of each item provided 
by a downloading is always explicit, no indication is given of its kind (i.e., 
whether it is an ordinary, generic, or architectural specification, or a view) nor 
of what symbols it declares. Thus the well-formedness of a library depends on 
what items are actually downloaded from other libraries. 

The construct ‘from . . . get . . . ’ above has the effect of downloading the 
specifications that are named Nat and Int in Basic/Numbers, preserving 
their names. It is also possible to give downloaded specifications different 
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names, e.g., to avoid clashes with specification names that are already in use 
locally: 

from Basic/Numbers get Nat Natural, Int i— *■ Integer 

Items that are referenced by downloaded items are not themselves auto- 
matically downloaded, e.g., downloading Int does not entail the downloading 
of Nat. This is because downloading involves the semantics of the named 
items, not their text. The semantics of Int consists of a signature and a class 
of models, and is a self-contained entity - recall from Chap. 6 that the models 
of a structured specification have no more structure than do those of a fiat, 
unstructured specification. Thus downloading Int gives exactly the same re- 
sult as if the reference to Nat in its text had already been replaced by the text 
of Nat before downloading. For the same reason, the presence of another item 
with the name Nat in the current library makes no difference to the result of 
downloading Int. In terms of software packages, downloading specifications 
from Case libraries is analogous to installing packages from binaries, rather 
than from sources. 

Downloading any item from another library B in a library A causes all the 
parsing and display annotations of B to be inserted at the beginning of A. 
(Conflicting annotations from different libraries are ignored altogether, and 
local annotations override conflicting downloaded annotations.) The copied 
annotations allow terms to be written and displayed in A in the same way as 
in B. 



Substantial libraries of basic datatypes are already available. 



The organization of the following libraries of basic datatypes is explained 

in Chap. 12: 

Basic/Numbers: natural numbers, integers, and rationals. 

Basic/RelationsAndOrders: reflexive, symmetric, and transitive rela- 
tions, equivalence relations, partial and total orders, boolean algebras. 

Basic/Algebra J: monoids, groups, rings, integral domains, and fields. 

Basic/ SimpleDatatypes: booleans, characters. 

Basic/StructuredDatatypes: sets, lists, strings, maps, bags, arrays, trees. 

Basic/Graphs: directed graphs, paths, reachability, connectedness, colorabil- 
ity, and planarity. 

Basic/Algebra JI: monoid and group actions on a space, euclidean and 
factorial rings, polynomials, free monoids, and free commutative monoids. 

Basic/LinearAlgebra J: vector spaces, bases, and matrices. 

Basic/LinearAlgebra JI: algebras over a field. 

Basic/MachineNumbers: bounded subtypes of naturals and integers. 
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These libraries form a coherent collection of highly-polished specifications. 
The libraries themselves are provided in full in the Casl Reference Manual 
[20], and are available on the Internet. 




Libraries need not be registered for public access. 



library http ; //www. cof i . inf o/CASL/Test /Security 

from http : //casl :password@www. cof i . inf o/CASL/RSA get Key 

spec Decrypt = Key then . . . 

Libraries under development, and libraries provided for restricted groups 
of users, are named and accessed by their URLs (instead of the simple path 
names used for registered libraries). This allows the Casl library constructs 
to be fully exploited for libraries that are not yet - and perhaps never will 
be - registered for public access. Moreover, validation of libraries can be a 
demanding and time-consuming process, and getting a library approved and 
registered is appropriate only when it provides specifications that are likely 
to be found useful by persons not directly involved in its development. 

The primary Internet access protocols HTTP and FTP both support pass- 
word protection of libraries and the insertion of usernames and passwords in 
URLs allows downloading between protected libraries (With HTTP, the user- 
name and password can be unrelated to those used for the host file system.) 



9.3 Version Control 

Subsequent versions of a library are distinguished by explicit version 
numbers. 

f ~ 

library Basic/Numbers version 1.0 
spec Nat = . . . 
spec Int = Nat then . . . 
spec Rat = Int then . . . 
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As illustrated above, a library can be assigned an explicit version num- 
ber, allowing it to be distinguished from previous and future versions of the 
same library. Casl allows conventional hierarchical version numbers, familiar 
from version numbers of software packages: the initial digits indicate a major 
version, digits after a dot indicate sub-versions, and digits after a further dot 
indicate patches to correct bugs. (Distinctions between alpha, beta, and other 
pre-release versions are not supported.) 

The smallest version number is written simply ‘O’, and can be omitted 
when specifying the initial version of a library; this is the case with the version 
of Basic/Numbers shown in Sect. 9.2, it implicitly has version number ‘O’, 
but in general the first-installed version of a library could have any version 
number at all. The numbers of successively installed versions do not have to 
be contiguous, nor even increasing: e.g., a patched version 0.99.1 could be 
installed after version 1.0. 

Individual library items do not have separate version numbers. Date anno- 
tations can be used to indicate which items have changed between two versions 
of a library. 



Libraries can refer to specific versions of other libraries. 


L 
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library Basic/ StructuredDatatypes version 1.0 
from Basic/Numbers version 1.0 get Nat, Int 
spec List [sort Elem] given Nat = . . . 
spec Array . . . given Int = . . . 

Downloading items from particular versions of libraries is necessary if one 
wants to ensure coherence between libraries. For example, as illustrated above, 
version 1.0 of Basic/ StructuredDatatypes downloads Nat and Int from 
version I.O of Basic/Numbers. Omitting the version number when down- 
loading gives implicitly the current version of the library, which may of course 
change. By the way, the current version of a library is not necessarily the one 
most recently installed: it is the one with the largest version number. As pre- 
viously mentioned, a patched version 0.99.1 could be installed after version 
1.0, but a downloading without an explicit version number would still refer to 
version 1.0. 

Even though the developers of libraries may try to ensure backwards com- 
patibility between versions, it could happen that symbols introduced in a new 
version of a downloaded specification clash with symbols already in use in 
the library that specified the downloading, causing ill-formedness or incon- 
sistency. So for safety, it is advisable to give explicit version numbers when 
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downloading (also when downloading from version ‘0’ of another library). If 
one subsequently wants to use symbols that are introduced only in some later 
version of another library, all that is needed is to change the version number 
in the downloading(s). 

An alternative strategy is to ensure consistency with the current versions 
of all libraries from which specifications are downloaded, by observing the 
changes in the new versions and adapting the downloading library accord- 
ingly. For instance, one might download Int from the current version of Ba- 
SIC/Numbers, instead of from version 1.0 of that library. This may involve 
extra work when a new version of Basic/Numbers appears, but it has sev- 
eral advantages over the more cautious approach. Case leaves the choice to 
the user, although registered libraries will generally be required to use explicit 
version numbers when downloading from other libraries. 



All downloadings should be collected at the beginning of a library. 



Although Case allows downloadings to be interleaved with specification 
definitions, it is advisable to collect the downloadings at the beginning of 
libraries (together with any parsing and display annotations). This makes 
it easy to see dependencies between libraries, and to ensure that different 
downloadings from the same library all refer to the same version of it. 
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Donald Sannella and Andrzej Tarlecki 



V, 



A complete presentation of Casl is in the Reference Manual. 



This User Manual has introduced the potential user to the features of Casl 
mainly by means of illustrative examples. It has presented and discussed the 
typical ways in which the language concepts and constructs are expected to be 
used in the course of building system specifications. Thus, the presentation in 
Part II focused on what the constructs and concepts of Casl are for, and how 
they should (and should not) be used. We tried to make these points as clear 
as possible by referring to simple examples, and by discussing both the general 
ideas and some details of Casl specifications. We hope that this has given the 
reader a sufficient feel of the formalism, and enough understanding, to look 
through the presentation of a basic library of Casl specifications in Chap. 12, 
to follow the case study in Chap. 13, and to start experimenting with the 
use of Casl for writing specifications - perhaps employing the support tools 
presented in Chap. 11. 

By no means, however, should this book be regarded as a complete presen- 
tation of the Casl specification formalism - this is given in the accompanying 
volume, the Casl Reference Manual [20]. 



Casl has a definitive summary. 


L 


[ 





The Casl Reference Manual begins with a definitive summary of the en- 
tire Casl language: all the language constructs are listed there systematically, 
together with the syntax used to write them down and a detailed explana- 
tion of their intended meaning. However, although it tries to be precise and 
complete, the Casl Summary still relies on natural language to present Casl. 
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This inherently leaves some room for interpretation and ambiguity in vari- 
ous corners of the language, for example where details of different constructs 
interact. 

k 



Casl has a complete formal definition. 



A key aim of the entire CoFI initiative is to avoid any potential ambiguities 
by providing a complete formal definition for Casl, and sound mathematical 
foundations for the advocated methodology of its use in software specification 
and development. 



Abstract and concrete syntax of Casl are defined formally. 



The next part of the Reference Manual is a formal definition of the syntax 
of Casl. Abstract syntax is given, where each phrase is written in a way that 
directly indicates its components, thus making evident its internal structure. 
In essence, the use of each construct of the language is explicitly labeled 
here. This is convenient for formal manipulation and analysis, but is not so 
readable. Therefore, the so-called concrete syntax of Casl (as used for instance 
in the examples throughout this book) is given as well, retaining a direct 
correspondence with the abstract syntax. This offers to the user of Casl a 
convenient and readable way of writing down Casl specifications, in a way 
that makes clear the formal structure of the phrases and constructs used to 
build them. As usual, the syntax is given as a context-free grammar, using 
a variant of the BNF notation, relying on well-established theory to give its 
formal meaning, and on a variety of tools and techniques available for syntactic 
analysis of languages presented in such a style. 



V, 



Casl has a eomplete formal semantics. 



The ultimate definition of the meaning of Casl specifications is provided 
by the semantics of Casl in the Reference Manual. The semantics first defines 
mathematical entities that formally model the intended meaning of various 
concepts underlying Casl, as already hinted at in Chap. 2, and further intro- 
duced and discussed throughout the summary. 

The key concepts here are that of Casl signature, model and formula, 
together with the satisfaction relation between models and formulas over a 
common signature. In fact, these are variants of the standard algebraic and 
logical notions, thus linking work on Casl to well-established mathematical 
theories and ideas. 
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In a more or less standard way, we use these concepts to build the semantic 
domains which the meanings of phrases in various syntactic categories of Casl 
inhabit. We have chosen to give the semantics in the form of so-called natural 
semantics, with formal deduction rules to derive judgments concerning the 
meaning of each Casl phrase from the meanings of its constituent parts. Not 
only is this a mathematically well-established formalism with an unambiguous 
interpretation, but we also hope that this makes the semantics itself more 
readable, with details easier to follow than in some other approaches. 

The overall semantics of Casl consists of two parts. The static semantics 
captures a form of static analysis of Casl specifications, in which they are 
checked for well-formedness - for example, that axioms are we 11- typed, and 
references to named entities are in scope. Then the model semantics takes a 
well-formed Casl specification and assigns a model-theoretic meaning to it. 

1-, 



Casl specifications denote classes of models. 



In Casl, well-formed specifications denote signatures (static semantics) 
and classes of models (model semantics). Basic specifications, which in essence 
present a signature and a set of axioms over this signature, denote the class 
of models that satisfy all the axioms. The semantics of basic specifications is 
split into two parts: first many-sorted basic specifications are described and 
then features for defining and using subsorts are added. 



The semantics is largely institution-independent. 



A few more concepts are needed to explain the semantics of structured 
specifications. Key here is the notion of signature morphism, and the model 
reducts and translation of sentences that signature morphisms induce. Having 
introduced those, we obtain the institution [23] of Casl, that is, the under- 
lying logical system of Casl equipped with extra structure to capture ways 
of moving between signatures linked by signature morphisms. One important 
point of the semantics is that all the layers of the semantics “above” basic 
specifications are institution-independent, i.e., well-defined for any institution 
chosen to build basic specifications (as long as the institution comes with a bit 
of extra structure concerned with forming unions of signatures and defining 
signature morphisms). 

Next, we have the semantics of architectural specifications, which relies 
on a formal counterpart of the concept of a unit (module) of a system to be 
developed: self-contained units are viewed simply as models of the underly- 
ing institution, and parametrized units as functions mapping such parameter 
models to result models. Architectural specifications provide a way of speci- 
fying the component units of a system and indicating how the overall system 
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is built by putting these units together. This intuition is captured by the se- 
mantics of architectural specifications, which denote a class of permitted unit 
bindings and a function that maps each such environment to a result unit. 

Finally, the libraries layer of Casl is given a rather standard description 
with libraries modeled as environments giving names to the entities introduced 
(specifications, architectural specifications, etc.). 



The semantics is the ultimate reference for the meanings of all Casl 
constructs. 



Overall, the formal mathematical semantics is crucial in the understanding 
of Casl specifications. It provides their unambiguous meaning, and thus gives 
the ultimate reference point for all questions concerning the interpretation of 
any Casl phrase in any context. 

We have already experienced how important such a formal semantics may 
be in the design of Casl itself. In many cases, the intended semantics was 
prominent in internal discussions on the details of the constructs under con- 
sideration, and provided guidelines for many choices in the design of Casl. 
Indeed, the concrete syntax of Casl was designed only after the semantics 
was settled. 



V, 



Proof systems for various layers of Casl are provided. 



The semantics is also a necessary prerequisite for the development of mech- 
anisms for formal reasoning about Casl specifications. This is the role of proof 
calculi that support reasoning about the various layers of Casl. The starting 
point is a formal system of deduction rules which determines a proof-theoretic 
counterpart of the consequence relation between sets of formulas, thus provid- 
ing a way for deriving consequences of sets of axioms in Casl specifications. 
This is then extended to systems of rules for deriving consequences of struc- 
tured specifications and for proving inclusions between classes of models of 
such specifications. These systems are also used in rules for formal verification 
of the internal correctness of system designs as captured by architectural spec- 
ifications. For all these systems, their soundness is proved and completeness 
discussed by reference to the formal semantics of Casl. 

One point of interest is that, again, the extension of the basic proof system 
for consequences between sets of formulas to structured and architectural 
specifications does not really rely on the specifics of the underlying institution, 
but just reflects the way in which the structuring and architectural constructs 
are defined for an arbitrary institution. 
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The foundations of our Casl are rock-solid! 


L 


[ 





All this work on the mathematical underpinnings of Casl and related 
specification and development methodology, as documented in the Reference 
Manual, should make it exceptionally trustworthy - at least in the sense that 
it provides a formal point of reference against which all the claims may (and 
should) be checked. 
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Tools 



Till Mossakowski 



This chapter gives an overview of the Casl tools. Analysis tools for Casl like 
parsers and static checkers, as well as formatters, are stable now and cover 
the whole of Casl. Proof tools are available but are less mature. 

Casl has been designed with the goal of subsuming many previous spec- 
ification languages. Most of these languages come with specific tools, and of 
course, these tools should be reusable in the context of Casl. Hence, a central 
issue is to build bridges to existing tools (rather than building new tools from 
scratch). Using an interchange format generated by the analysis tools, Casl 
has been interfaced in this way to rewriting engines and theorem provers, 
usually working for a subset of Casl. 

Naturally, due to the ongoing development of these tools, detailed descrip- 
tions would become outdated sooner or later. Therefore, we give here just an 
appetizer, intended to encourage the reader to install the tools and experiment 
with them (and to convince her/him that this is rather easy). More detailed 
descriptions of the tools, as well as their latest versions and other tools that 
may be developed in the future, are available by following the links on the 
CoFI tools home page [21]: http://www.cofi.info/Tools. 

The analysis tools for Casl have been used to check all the examples 
contained in this book, as well as the Casl Basic Libraries [20]. Moreover, 
some proofs from a case study in refinement have been carried out with the 
proof tools. 



Casl specifications can be checked for well-formedness using a 
form-based web page. 



The easiest way to check a Casl specification for well-formedness is to 
visit the web interface. Using a web form, you can submit your specification 
(without the need to install anything on your machine), and get immediate 



M. Bidoit and P.D. Mosses: CASL User Manual, LNCS 2900, pp. 131—142, 2004. 
(c) IFIP International Federation for Information Processing 2004 



132 



11 Tools 



feedback about the well-formedness of the specification. Follow the “web in- 
terface” link on the CoFI tools home page. 



11.1 The Heterogeneous Tool Set (Hets) 



V, 



The Heterogeneous Tool Set (Hets) is the main analysis tool for 
Case. 



Hets is a tool set for the analysis of specifications written in Case, its 
extensions and sublanguages - hence the name “heterogeneous”. Hets con- 
sists of logic-specific tools for the parsing and static analysis of the different 
Case extensions and sublanguages, as well as a logic-independent parsing and 
static analysis tool for structured and architectural specifications and libraries 
(which of course calls the logic-specific tools whenever a basic specification is 
encountered). In order to be able to tackle proof obligations occurring in 
(statically well-formed) specifications, Hets is interfaced with various logic- 
specific theorem proving, rewriting and consistency checking tools. On top of 
this, there is a logic-independent proof engine called Maya, which manages 
the proof obligations. Maya uses so-called development graphs, a graphical 
representation of Case structured specifications. 

The architecture of Hets is shown in Fig. 11.1. The latest version can be 
obtained from the CoFI tools home page [21]. Installation is easy; just follow 
the instructions. 

Consider the first example in this book: 

spec Strict _Partiae_Order = 
sort Elem 

pred Elem x Elem 

Vx, y, z : Elem 

• ~^(x < x) %(strict)% 

• X < y ^ —‘{y < x) % (asymmetric) % 

• x<y/\y<z^x<z % (transitive) % 

%{ Note that there may exist x, y such that 

neither x < y nor y < x. }% 

end 



Hets can be used for parsing and checking static well-formedness of 
specifications. 
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Fig. 11.1. Architecture of the heterogeneous tool set. 



Let us assume that the example is in a file named Order . casl (actually, 
this file is provided on the web and on the CD-ROM coming with this volume) . 
Then you can check the well-formedness of the specification by typing (into 
some shell): 

hets Order. casl 

Hets checks both the correctness of this specification with respect to the 
Case syntax, as well as its correctness with respect to the static semantics 
(e.g. whether all identifiers have been declared before they are used, whether 
operators are applied to arguments of the correct sorts, whether the use of 
overloaded symbols is unambiguous, and so on). 

It is also possible to generate a pretty printed DT[;]X version of Order . casl 
by typing: 

hets -o pp.tex Order. casl 

One use of Order . casl might be to express the fact that the natural 
numbers form a strict partial order as a view, as follows: 

spec Natural = free type Nat ::= 0 \ suc(Nat) end 
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spec Natural_Order_2 = 

Natural 

then pred Nat x Nat 

Vx, y : Nat 

• 0 < suc(x) 

• < 0 

• suc(x) < suc(y) 4^ X < y 

end 

view vl : Strict_Partial_Order to Natural_Order_2 = 

Elem I— !■ Nat 

end 

Again, these specifications can be checked with Hets. However, this only 
checks syntactic and static semantic well-formedness - it is not checked 
whether the predicate introduced in Natural_Order_2 actually 

is constrained to be interpreted by a strict partial ordering relation. Checking 
this requires theorem proving, which will be discussed below. 



Hets also displays and manages proof obligations, using development 
graphs. 



However, before coming to theorem proving, let us first inspect the proof 
obligations arising from a specification. This can be done with: 

hets -g Order. casl 

(assuming that the above two specifications and the view have been added to 
the file Order . casl). Hets now displays a so-called development graph (which 
is just an overview graph showing the overall structure of the specifications 
in the library), see Fig. 11.2. 




Fig. 11.2. Sample development graph. 
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Nodes in a development graph eorrespond to Casl speeifieations. 
Arrows show how speeifieations are related hy the structuring 
constructs. 



The solid arrow denotes an ordinary import of specifications (generated 
by the extension), while the dashed^ arrow denotes a proof obligation (corre- 
sponding to the view). This proof obligation needs to be discharged in order 
to show that the view is well-formed. 

As a more complex example, consider the following loose specification of 
a sorting function, taken from Chap. 6: 
spec List_Order_Sorted 

[Total_Order with sort Elem, pred __ < __] = 

List_Selectors [sort Elem] 
then local pred ^Assorted : List 
Ve, e' : Elem] L : List 

• empty issorted 

• cons(e, empty) issorted 

• cons(e, cons(e' , L)) is-sorted 

(cons(e' , L) issorted A ~^{e' < e)) 
within op order : List — > List 

VL : List • order{L) issorted 

end 

The following specification of sorting by insertion also is taken from 
Chap. 6: 

spec List_Order [Total_Order with sort Elem, pred __ < __] = 
List_Selectors [sort Elem] 
then local op insert : Elem x List — > List 
Ve, e' : Elem] L : List 

• insert {e, empty) = cons{e, empty) 

• ins ert(e, cons (e', L)) = cons(e', insert (e, L)) when e' < e 

else cons{e, cons{e' , L)) 

within op order : List — > List 
Ve : Elem] L : List 

• order {empty) = empty 

• order{cons{e, L)) = insert{e, order{L)) 

end 

Both specifications are related. To see this, we first inspect their signatures. 
This is possible with: 

hets -g Sorting. casl 

^ Actually, the dashed arrow will be displayed as solid and in red by HetS; we do 
not have colors available here. 
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assuming that Sorting, casl contains the above specifications. Hets now 
displays a more complex development graph, see Fig. 11.3. 




Fig. 11.3. Development graph for the two sorting specifications. 
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Internal nodes in a development graph correspond to unnamed parts 
of a structured specification. 



In the above-mentioned development graph, we have two types of nodes. 
The named ones correspond to named specifications, but there are also un- 
named nodes corresponding to anonymous basic specifications like the dec- 
laration of the insert operation in List_Order above. Basically, there is an 
internal node for each structured specification that is not named. 

Again, the simple solid arrows denote an ordinary import of specifications 
(corresponding to the extensions and unions in the specifications), while the 
double arrows denote hiding (corresponding to the local specification). 

By clicking on the nodes, one can inspect their signatures. In this way, 
we can see that both List_Order_Sorted and List_Order have the same 
signature. Hence, it is legal to add a view: 

view v2[Total_Order] : List_Order_Sorted[Total_Order] to List. 
Order[Total_Order] 

end 

We have already added this view to Sorting. casl. The corresponding 
proof obligation between List_Order_Sorted and List.Order is displayed 
in Fig. 11.3 as a dotted arrow. 



V, 



Proof obligations can be discharged in various ways. 



Trivial proof obligations can be discharged by Hets alone using the 
“Proofs” menu. The proof obligation in Fig. 11.3, indicated by the lower dotted 
arrow between List_Order_Sorted and List.Order, states that insertion 
sort, as defined by the operation order in List.Order, actually has the prop- 
erties of a sorting algorithm. Here, one has to choose a theorem prover that 
is to be used to discharge the proof obligation, which is then done by using 
commands specific to the theorem prover (cf. e.g. Section 11.2). Alternatively, 
one can state that one just conjectures the obligation to be true. 

Hets is written in Haskell. Its parser uses combinator parsing. The user- 
defined (also known as “mixfix”) syntax of Case calls for a two-pass approach. 
In the first pass, the skeleton of a Case abstract syntax tree is derived, in order 
to extract user-defined syntax rules. In a second pass, which is performed 
during static analysis, these syntax rules are used to parse any expressions 
that use mixfix notation. The output is stored in the so-called ATerm format 
[12], which is used as interchange format for interfacing with other tools. 

Hets provides an abstract interface for institutions, so that new logics can 
be integrated smoothly. In order to do so, a parser, a static checker and a 
prover for basic specifications in the logic have to be provided. 
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Hets has been built based on experiences with its precursors, Cats and 
Maya. The Case Tool Set (Cats) [28, 30] comes with roughly the same anal- 
ysis tools as Hets. The management of development graphs is not integrated 
in Cats, but is provided with a stand-alone version of the tool Maya [5, 4]. 
Cats and Maya can be obtained from the CoFI tools home page [21]. 



11.2 Hol-Casl 



Hol-Casl is an interactive theorem prover for Casl, based on the 
tactical theorem prover Isabelle. 



The Hol-Casl system [28] provides an interface between Casl and the 
theorem proving system Isabelle/Hol [31]. We have chosen Isabelle be- 
cause it has a very small core guaranteeing correctness, and its provers, like 
the simplifier or the tableaux prover, are built on top of this core. Further- 
more, there is over ten years of experience with it, and several mathematical 
textbooks have been partially verified with Isabelle. 



V, 



Casl is linked to Isabelle/Hol by an encoding. 



Since subsorting and partiality are present in Casl but not in Isabelle/Hol, 
we have to encode these features, as explained in [29] . This means that theorem 
proving is not done in the Casl logic directly, but in the logic Hol (for higher- 
order logic) of Isabelle. Hol-Casl tries to make the user’s life easy by: 

• choosing a shallow embedding of Casl into Hol, which means that e.g. 
Case’s logical implication => is mapped directly to Isabelle/Hol’s logical 
implication — > (and the same holds for other logical connectives and 
quantifiers); and 

• adapting Isabelle/Hol’s syntax to conform with the Casl syntax, e.g. 
Isabelle/Hol’s — > is displayed as =>, as in Casl. 

However, it is essential to be aware of the fact that the Isabelle/Hol logic is 
different from the Casl logic. Therefore, the formulas appearing in subgoals of 
proofs with Hol-Casl will not fully conform to the Casl syntax: they may use 
features of Isabelle/Hol such as higher-order functions that are not present 
in Casl. Hol-Casl can be obtained from the CoFI tools home page [21]. 

To start the Hol-Casl system, follow the installation instructions, and 
then type: 



HOL-CASL 
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You can load the above specification file Order . casl by typing: 
use_casl "Order"; 

Let us try to prove part of the view vl above. To prepare for conducting 
a proof in the target specification of the view, Natural_Order_2, type in: 

CASL_context Natural_0rder_2 . casl ; 

AddsimpAll 0 ; 

The first command just selects the specification as the current proof context; 
the second one adds all the axioms of the specification to Isabelle’s simplifier 
(a rewriting engine). Note that the latter is advisable only if the axioms are 
terminating, when considered as a set of rewrite rules. 

To prove the first property expressed by the view, we first have to type 
in the goal. Then we chose to perform induction over the variable x, and the 
rest can be done with automatic simplification. Finally, we name the theorem 
for later reference: 

Goal "forall x:Nat . not x<x" ; 
by (induct_tac "x" 1) ; 
by Auto_tac; 
qed "Nat_irref lexive" ; 

Both the stand-alone Maya as well as the Maya part of Hets also provide 
an interface to Hol-Casl, so that it can be used to discharge proof obligations 
arising in development graphs. 



11.3 Asf+Sdf Parser and Syntax-Directed Editor 



Asf+Sdf was used to prototype the Casl syntax. 



The algebraic specification formalism Asf-|-Sdf [22] and the Asf-|-Sdf 
Meta-Environment [13] have been deployed to prototype Case’s concrete syn- 
tax, and to develop a mapping for the concrete syntax to an abstract syntax 
representation using so-called ATerms [12]. Currently, only the first pass of 
parsing (i.e. without mixfix analysis) is realized in SDF. Parsing is performed 
based on the underlying Scannerless Generalized LR parsing technology. A 
prototype of the mapping from the concrete to abstract representation is writ- 
ten in ASF rewrite rules. 
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The Asf+Sdf Meta- Environment provides syntax- directed editing of 
Casl specifications. 



Given the concrete syntax definition of Casl in SDF, syntax-directed ed- 
itors within the Asf-|-Sdf Meta-Environment come for free. Recent develop- 
ments in the Meta-Environment even allow for the development of a Casl 
specification environment. 

The Asf-|-Sdf Meta-Environment provides a built-in library mechanism 
which contains a collection of grammars, among others Casl. Via the library 
the user of the Meta-Environment has access to the Casl syntax in SDF and 
a collection of ASF equations to map Casl specifications into an interchange 
format named CasFix. The asfc tool compiles the Casl grammar into a 
stand-alone C program. 

A link to the Asf-|-Sdf Meta-Environment with further information and 
a download possibility can be found at the CoFI tools home page [21]. The 
built-in library of the Meta-Environment (Version 1.5 and higher) will pro- 
vide the full Casl grammar in SDF and the mapping to CasFix as an ASF 
specification. 



11.4 Other Tools 

The following tools are at a prototype stage at the time of appearance of this 
volume. Please refer to at the CoFI tools home page [21], where the latest 
versions can be downloaded. 

Translation to OCAML 

A translation from Casl into OCAML has been developed at Paris and 
Poitiers. The translation works for a “functional programming” sublanguage 
of Casl that includes free datatypes and recursive definitions of operations 
over these types. 

Translation to Haskell 

A translation from Casl into Haskell has been developed in Bremen. Actually, 
the translation works on an executable subset of HasCasl (a higher-order ex- 
tension of Casl). Using an embedding of Casl into HasCasl, this translation 
can also be used for Casl. 

Elan- Casl 

Elan-Casl is a rewriting engine for the Horn= sublanguage of Casl. It is 
based on a translation of that sublanguage to the input language of the rewrit- 
ing engine Elan. 
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Given a Casl specification and a query term, Elan-Casl computes the 
normal forms of the term. Note that because the set of rules is not required to 
be terminating nor confluent, a query term may have several normal forms, 
or may not terminate. 

Elan can be called either as an interpreter or as a compiler. 

Casl consistency checker 

The Casl consistency checker (CCC) has been developed in Bremen and 
Swansea. With CCC, one can interactively check whether a Casl specification 
is consistent. It is a faithful implementation of a consistency calculus for full 
Casl [32]. 

Besides using certain syntactical criteria, the consistency calculus relies 
heavily on the Casl structuring mechanisms and their semantic annotations. 
Consequently, consistency proofs follow the structure of the given specifica- 
tion. In this way, the calculus highlights the (usually few) ‘hot spots’ of a 
specification (e.g. views requiring theorem proving), while the (lengthy) ‘triv- 
ial’ parts of the consistency argument are discharged automatically. As the 
consistency calculus works along the structure of the specification, the need 
to construct (and prove correct) actual models of specifications is avoided as 
far as possible. 
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The Casl Consistency Checker consists of four parts (see Fig. 11.4): first, 
a logical core implementing a representation of the propositions to be proved, 
and the basic proof rules, along with a generic unification package for the 
Casl abstract syntax; secondly, representations of the calculi: the base rules 
which are stated axiomatically, and derived rules; thirdly, proof procedures 
(automatic or semi-automatic decision procedures), which serve to discharge 
specific proof obligations; and finally, proof infrastructure such as a package 
which helps users to conduct goal-directed proofs, tactics that support writing 
advanced proof procedures, and a simple database which allows storage and 
retrieval of proved theorems. The system is encapsulated by a single interface 
which does not allow the end-user (i.e. the working specifier) to add any more 
axiomatic rules or provers; thus, the typing is used to both increase confidence 
in the correctness of the implementation in the style of LCF, and to protect 
the integrity of the system from user intervention. 
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Till Mossakowski 



The Casl Basic Libraries contain the standard datatypes. 



The Casl Basic Libraries consist of specifications of often-needed datatypes 
and views between them, freeing the specifier from re-inventing well-known 
things. This can be compared to standard libraries in programming languages. 
While this book often discusses several styles of specification with Casl, the 
basic datatypes consistently follow a specific style described in [20]. 






Here we show a cut-down version without axioms. 



Here, we describe two of the libraries (see the overview in Fig. 12.1): the 
libraries of numbers and of structured datatypes. We also provide stripped- 
down versions of the libraries themselves, with some of the specifications and 
all axioms and annotations removed. These stripped-down versions can serve 
for getting a first overview of the signatures of the specified datatypes. 

The full Casl Basic Libraries with complete specifications is presented in 
the Casl Reference Manual [20], and is also included in the CD-ROM coming 
with this volume. The latest version is available at: 

http : //www. cof i . inf o/Libraries 



Hets can be used to get an overview of the Basic Libraries. 



The Hets tool described in Chap. 11 allows the structure of the specifi- 
cations in the libraries to be displayed as a graph and their signatures to be 
inspected. This is recommended as a way of obtaining a better overview, and 
also for answering specific questions that arise when using the basic datatypes. 
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12 Basic Libraries 




Fig. 12.1. Dependency graph of the libraries of basic datatypes. 



12.1 Library Basic/ NUMBERS 



This library provides specifications of natural numbers, integers, and rational 
numbers. 



The natural numbers are specified as a free datatype. 


L 


[ 





In the specification Nat, the natural numbers are specified as a free 
datatype, together with a collection of predicates and operations over the 
sort Nat of natural numbers. 

Note that the names for the partial operations subtraction and 

division include a question mark. This is to avoid overloading with the 

total operations __ — __ on integers and on rationals, which would lead 
to inconsistencies as both these specifications import the specification Nat. 
The total operation for subtraction differs from subtraction on the integers as 
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well. It is written and it is 0 whenever the partial subtraction — ? is 

undefined, while it otherwise coincides with the latter. 

The digits are introduced as constants, together with an operation 
for concatenation of digits. Together with an annotation (see Chap. 9): 

%number 

this allows one to write the usual literals (like e.g. 8364) for natural numbers. 

The introduction of the subsort Pos, consisting of the positive naturals, 
gives rise to certain new operations, e.g.: 

__ X : Pos X Pos Pos, 

whose semantics is completely determined by overloading. 

library Basic/Numbers 
spec Nat = 

free type Nat ::= 0 \ suc{pre:?Nat) 

preds — <— , — >— , — <— , : Nat x Nat; 





even, odd : Nat 




Ops 





: Nat — > Nat; 








+ , X , ^ , min, max. 


: Nat x Nat Nat; 







— — /?— ) —div—, —mod__. 


ged : Nat x Nat — >? Nat 




%% Operations to represent natural 


numbers with digits: 


ops 


1 


Nat = suc{0); 


%(l_def_Nat)% 




2 


Nat = suc{l ); 


%(2_def_Nat)% 




3 


Nat = suc{2); 


%(3_def_Nat)% 




4 


II 


%(4_def_Nat)% 




5 


II 


%(5_def_Nat)% 




6 


II 


%(6_def_Nat)% 




7 


II 


%(7_def_Nat)% 




8 


II 


%(8_def_Nat)% 




9 


Nat = suc{8); 


%(9_def_Nat)% 






@@__(m: Nat; n: Nat): Nat = (m X suc{9)) + n 








% (decimaLdef) % 


sort 


Pos = {p\ Nat • p > 0} 




Ops 


1 


Pos = suc{0); 


% ( 1 _as_Pos _def ) % 







x__ : Pos X Pos Pos; 









+__ : Pos X Nat Pos; 








+__ : Nat X Pos Pos; 





sue : Nat —f Pos 



end 



The integers are speeified as difference pairs of naturals. 
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The specification Int of integers is built on top of the specification Nat: 
integers are defined as equivalence classes of pairs of naturals written as dif- 
ferences — the axioms (which are omitted in the specification below) specify 
that two pairs are equivalent if their differences are equal: 

V a, b, c, d: Nat 

• a— b = c— d^a + d = c+ b % (equality Jnt)% 

The sort Nat is then declared to be a subsort of Int. Besides the division 
operator i the specification Int also provides the function pairs div /mod 
and quot/rem, respectively, as constructs for division — behaving differently 
on negative numbers, see [20] for a discussion. The operation sign gives the 
sign of an integer (which is either -1, 0, or 1). 

spec Int = 

Nat 

then generated type Int ::= __—__{Nat; Nat) 
sort Nat < Int 

%% a system of representatives for sort Int is 
%% a - 0 and 0 - p, where a: Nat and p: Pos 
preds — <— , — >— , — <— , : Int x Int] 

even, odd : Int 
ops — — , sign : Int —>■ Int] 
abs : Int Nat] 

, — x__, min, max : Int x Int - 

: Int X Nat — > Int] 

—div—, —quot__, _jrem__ : Int x Int 
_jmod__ : Int X Int — >? Nat 

end 



Int] 

>? Int] 



The rationals are specified as fractions of integers. 


L 


[ 





The specification Rat of rational numbers follows the same scheme as 
the specification of integers discussed above. This time, the specification Int 
is imported. The rationale are then defined as equivalence classes of pairs 
consisting of an integer and a positive number written as fractions, using the 
axiom: 

V z, j: Int] p, q: Pos 

u i / p = j / q 4^ i X q = j X p %(equality_Rat)% 



The sort Int is then declared to be a subsort of Rat. Note that thanks to the 
behavior of subsorted overloading in Cast, the declaration of the operation: 
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: Rat X Rat Rat; 

allows rationals to be written also as x/y, for arbitrary integers x and y ^ 0 . 

spec Rat = 

INT 

then generated type Rat ::= ^/__{Int; Pos) 
sort Int < Rat 

preds — , — >— : Rat x Rat 
ops — — , abs : Rat —>■ Rat; 

__x__, min, max : Rat x Rat —>■ Rat; 

: Rat x Rat — >? Rat; 

__ : Rat X Int — > Rat 

end 



12.2 Library Basic/Structured DATATYPES 

This library provides specifications of the familiar structured datatypes as 
used e.g. for the design of algorithms or within programming languages. Its 
main focus is data structures like (finite) sets, lists, strings, (finite) maps, 
(finite) bags, arrays, and various kinds of trees. Common to all these concepts 
is that they are generic. Consequently, all of the specifications of this library 
are generic. 



Finite sets, maps and bags are specified as generated datatypes, with 
equality determined by means of observers. 



Finite sets, finite maps and finite bags are specified using a generated 
sort. An observer operation or predicate is then introduced in order to define 
equality on this sort. Concerning finite sets, equality on the sort Set[Elem] is 
characterized using the predicate —cps— (displayed as e) in the specification 
GenerateSet. This leads to the extensionality axiom: 

• M= N ^Wx : Elem •xeM^xeN yo{equality_Set)% 



library Basic / StructuredDatatypes 
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spec GenerateSet [sort Elem] = 

generated type Set[Elem] ::= {} | —+—{Set[Elem]-, Elem) 
pred __e__ : Elem x Set[Elem] 

%% a system of representatives for sort Set[Elem] is 

%% 

%% {} and {} + x_l + x_2 + ... + x_n 

%% 

%% where x_l < x_2 < ... < x_n, n >= 1, x_i of type Elem, 

%% for an arbitrary strict total order on Elem. 

end 

spec Set [sort Elem] given Nat = 

GenerateSet [sort Elem] 
then %def 

preds isNonEmpty : Set[Elem]; 

__C__ : Set[Elem] x Set[Elem] 
ops {__} : Elem — > Set[Elem]; 
tl__ : Set[Elem] — >■ Nat; 

: Elem x Set[Elem] — > Set[Elem]; 

: Set[Elem] x Elem —>■ Set[Elem]; 

..symDiff 

Set[Elem] x Set\Elem] Set[Elem] 

end 

Finite maps, i.e. elements of the sort Map\S , T], are considered to be 
identical if looking up any value in S yields the same result in both cases: 

• M= N^\/s : S • lookup{s, M) = lookup{s, N) %{equality-Map)% 

On top of this, the specification Map adds e.g. predicates for elementhood 
(e) as well as for determining the profile of a map (/ :: a; — > y means that / is 
a map from x to y). 

The specification TotalMap restricts maps to everywhere-defined maps 
(which are isomorphic to tuples). Since maps are finite, totality is only possible 
for maps over finite argument sorts. The latter is specified in the specification 
Finite, using a partial surjection from the natural numbers. Since this spec- 
ification is rather unusual, we make an exception and also show its axioms. 

spec GenerateMap [sort S] [sort T] = 

generated type Map[S,T] ::= empty ] __[__/ __](Map[6',T]; T; S) 
op lookup : S X Map[S,T] T 



end 
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spec Map [sort 6”] [sort T] given Nat = 

GenerateMap [sort 5] [sort T] 
and Set [sort S] 
and Set [sort T] 
then %def 

free type Entry[S,T] ::= [__/__]( tercet :T; source\S) 
preds isEmpty : Map[S,T]; 

__e__ : Entry [S,T] x Map[S,T]; 

: Map[S,T] X Set[S] x Set[T] 
ops Map[S,T] x Entry[S,T] Map[S,T]; 

: Map[S,T] X S ^ Map[S,T]; 

: Map[S,T] x T ^ Map[S,T]; 
dom : Map[S,T] Set[S]; 
range : Map[S,T] Set[T]] 

_.U__ : Map[S,T] x Map[S,T] Map[S,T] 

end 

spec Finite [sort Eleni] = 

{ Nat 

then op / : Nat — >? Elem 

• V x: Elem • 3 n: Nat • f{n) = x %(f.^urjective)% 

• 3 n: Nat • V m: Nat • def f{m) m < n %(f_bounded)% 

} 

reveal Elem 

end 

spec TotalMap [Finite [sort 5]] [sort T] = 

{ Map [sort S] [sort T] 
then sort TotalMap[S,T] = 

{M: Map[S,T] • \f x\ S • def lookup{x, M)} 
ops : TotalMap[S,T] x T X S ^ TotalMap[S,T]] 

lookup : S X TotalMap[S,T] T; 

TotalMap[S,T] x Entry[S,T] TotalMap[S,T]', 
range : TotalMap[S,T] — > Set[T]\ 

__U__ : TotalMap[S,T] x TotalMap[S,T] 

— >? TotalMap[S,T] 

pred __e__ : i?ntr?/[5', T] x TotalMap[S,T] 

} 

hide Map[S,T] 

end 

In the specification Generates AG, those elements of sort Bag[Elem] are 
identified that show the same number of occurrences (observed by the opera- 
tion freq) for all entries: 

• M = Vx : Elem • freq{M, x) = freq{N, x) % {equality -Bag)% 
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spec Generates AG [sort Elem] given Nat = 

generated type Bag[Elem] ::= {} | —+—{Bag[Elem\; Elem) 
op freq : Bag[Elem] x Elem — > Nat 

end 

spec Bag [sort Elem] given Nat = 

GenerateBag [sort Elem] 
then preds isEmpty : Bag[Elem]; 

__e__ : Elem x Bag[Elem]; 

__C__ : Bag[Elem] x Bag [Elem] 

ops : Elem x Bag[Elem] — > Bag[Elem]; 

: Bag[Elem] x Elem —>■ Bag[Elem]; 

__n__ : Bag[Elem] x Bag[Elem] — > Bag[Elem] 

end 



Lists are specified as a free datatype. 


L 


[ 





In the specification GenerateList, lists are built up from the empty list 
by adding elements in front. The usual list operations are provided: first and 
last select the first or last element of a list, while rest or front select the 
remaining list; counts the number of elements in a list, while freq counts 
the number of occurrences of a given element; take takes the first n elements 
of a list, while drop drops them. 

spec GenerateList [sort Elem] = 

free type List[Elem] ::= [] | __::__{first:? Elem; rest:? List[Elem]) 

end 

spec List [sort Elem] given Nat = 

GenerateList [sort Elem] 
then preds isEmpty : List[Elem]; 

__e__ : Elem x List[Elem] 
ops : List[Elem] x Elem List[Elem]; 

first, last : List[Elem] —^? Elem; 
front, rest : List[Elem] —^? List[Elem]; 

([__ : List[Elem] — > Nat; 

__H — h__ : List[Elem] x List[Elem] — > List[Elem]; 
reverse : List[Elem] —>■ List[Elem]; 

: List[Elem] x Nat — >? Elem; 
take, drop : Nat x List[Elem] — *■? List[Elem]; 
freq : List[Elem] x Elem Nat 



end 
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V, 



Arrays are specified as certain finite maps. 



The specification Array includes the condition min < max as an axiom 
in its first parameter. This ensures a non-empty index set. Arrays are defined 
as finite maps from the sort Index to the sort Elem, where the typical array 
operations lookup (— !— ) and assignment := __) are introduced in terms 
of finite map operations. Finally, revealing the essential signature elements 
yields the desired datatype. 

spec Array [ops min, max : Int • min < max %(Cond_nonEmptyIndex)%] 
[sort Elem] 
given Int = 

sort Index = {i: Int • min < i A i < max} 
then { Map [sort Index] [sort Elem] 

with sort Map[Index,Elem] i— > Array[Elem], 
op empty init 

then ops : Array[Elem] x Index x Elem Array[Elem]] 

: Array[Elem] x Index —>-7 Elem 

} 

reveal sort Array[Elem], ops init, 

end 



Several kinds of tree are available, differing in the branching and in 
the positions of elements. 



The library concludes with several specifications concerning trees. There 
are specifications of binary trees (BinTree, BinTree2), fc-branching trees 
(KTree), and trees with possibly different branching at each node (NTree). 
Each of these branching structures can be equipped with data in different 
ways: Either all nodes of a tree carry data (as is the case in BinTree, KTree, 
and NTree), or just the leaves of a tree have a data entry (as in BinTree2). 
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Binary trees admit two ehildren for eaeh internal node. 



spec GenerateBinTree [sort Elem] = 
free type 

BinTree[Elem] ::= nil 

I binTree{entry\l Elem\ left:! BinTree[Elem]; 
right :! Bin Tree [Elem]) 

end 

spec BinTree [sort Elem] given Nat = 

GenerateBinTree [sort Elem] and Set [sort Elem] 
then preds isEmpty, isLeaf : BinTree[Elem]] 
isCompoundTree : BinTree[Elem]; 

__e__ : Elem x BinTree[Elem] 
ops height : BinTree[Elem] Nat; 

leaves : BinTree[Elem] Set[Elem] 

end 

spec GenerateBinTree 2 [sort Elem] = 

free type NonEmptyBinTree2[Elem] ::= 
leaf ( entry:! Elem) 

I bin Tree (left:! NonEmptyBin Tree2 [Elem ] ; 

right: ! NonEmptyBin Tree2 [Elem ] ) 

free type BinTree2[Elem] ::= nil ] sort NonEmpty BinTree 2 [Elem] 

end 

spec BinTree 2 [sort Elem] given Nat = 

GenerateBinTree 2 [sort Elem] and Set [sort Elem] 
then %def 

preds isEmpty, isLeaf : BinTree2[Elem]; 
isCompoundTree : BinTree2[Elem]; 

__e__ : Elem x BinTree2[Elem] 
ops height : BinTree2[Elem] — > Nat; 

leaves : BinTree2[Elem] Set[Elem] 



end 
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k-trees admit k children for each internal node (with k fixed). 



We now come to fc-branching trees. The branching is specified by using 
arrays of trees of size k, which are used to contain the children of a node in 
the tree. 

spec GenerateKTree [op k : Int • k > 1 %(Cond_nonEmpty Branching) %] 

[sort Elem] given Int = 

Array [ops 1 : Int; k : Int 

fit ops min : Int 1, max : Int i— > k] 

[sort KTree[k,Elem\\ 
then free type 

KTree[k,Elem] ::= nil 

I kTree (entry:! Elem; 

branches : 7 Array [K Tree [k,Elem]]) 

end 

spec KTree [op k : Int • k > 1 %(Cond_nonEmpty Branching) %] 

[sort Elem] 
given Int = 

GenerateKTree [op k : Int] [sort Elem] 
and Set [sort Elem] 
then %def 

preds isEmpty, isLeaf : KTree[k^Elem]; 
isCompoundTree : KTree[k,Elem]; 

__e__ : Elem x KTree[k,Elem] 
ops height : KTree[k,Elem] — > Nat; 

maxHeight : Index x Array[KTree[k,Elem]] — > Nat; 

leaves : KTree[k,Elem] Set[Elem]; 

allLeaves : Index x Array[KTree[k,Elem]] — > Set[Elem] 



end 
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n -trees admit arbitrary branehing. 



Finally, n-trees are trees with possibly different branching at each node. 
This is specified by equipping each node in a tree with a list of child trees. 

spec GenerateNTree [sort Elem] = 

List [sort NTree[Elem]] 
then free type 

NTree[Elem] ::= nil 

I nTree (entry:! Elem; 

branches :? List [NTree [Mem]] ) 

end 

spec NTree [sort Elem] given Nat = 

GenerateNTree [sort Elem] and Set [sort Elem] 
then preds isEmpty, isLeaf : NTree[Elem]; 

isCompoundTree : NTree[Elem]; 

__e__ : Elem x NTree[Elem] 
ops height : NTree[Elem] Nat; 

maxHeight : List[NTree[Elem\\ — > Nat; 
leaves : NTree[Elem] — > Set[Elem]; 
allLeaves : List[NTree[Elem]] — > Set[Elem] 



end 
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Case Study: The Steam-Boiler Control System 



In this chapter we illustrate the use of Casl on a fairly large and complex case 
study, the steam-boiler control system. This case study is particularly interest- 
ing since it has been used several times as a competition problem, and many 
other specification frameworks have been illustrated with it, see [1]. Here we 
describe how to derive a Casl specification of the steam-boiler control system, 
starting from the informal requirements provided to the participants of the 
Dagstuhl meeting Methods for Semantics and Specification, organized jointly 
by Jean-Raymond Abrial, Egon Borger and Hans Langmaack in June 1995. 
The aim of this formalization process is to analyze the informal requirements, 
to detect inconsistencies and loose ends, and to translate the requirements into 
a Casl specification. During this process we have to provide interpretations 
for the unclear or missing parts. We explain how we can keep track of these 
additional interpretations by localizing very precisely in the formal specifica- 
tion where they lead to specific axioms, thereby taking care of the traceability 
issues. We also explain how the Casl specification is obtained in a stepwise 
way by successive analysis of various parts of the problem description. Finally 
we discuss the validation of the Casl requirements specification resulting from 
the formalization process, and in a last step we refine the requirements specifi- 
cation in a sequence of architectural specifications that describe the intended 
architecture of the steam-boiler control system.^ 



The reader not already familiar with the steam-boiler control system 
case study may want to start by reading App. C, where the original 
description of the problem is reproduced. 



^ This chapter partially relies on an earlier work published in [8] where the Pluss 
specification language [7, 9] was used together with the Larch prover [25]. How- 
ever, the specification methodology illustrated in this chapter is significantly im- 
proved, and moreover CASL provides several features that lead to a much more 
concise and perspicuous specification, as illustrated later in this chapter. 
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13.1 Introduction 

The aim of this chapter is to illustrate how one can solve the steam-boiler 
control specification problem with Casl. For this we have to provide a Casl 
specification of the software system that controls the level of water in the 
steam-boiler. Our work plan can be described as follows: 

1. The main task is to derive, starting from the informal requirements, a 
requirements specification, written in Casl, of the steam-boiler control 
system. In particular, this task involves the following activities: 

a) We must perform an in-depth analysis of the informal requirements. 
Obviously, this is necessary to gain a sufficient understanding of the 
problem to be specified, and this preliminary task may not seem worth 
mentioning. Let us stress, however, that the kind of preliminary anal- 
ysis required for writing a formal specification proves especially useful 
to detect discrepancies in the informal requirements that would other- 
wise be very difficult to detect. Indeed, from our practical experience, 
this step is usually very fruitful from an engineering point of view, 
and one could argue that the benefits to be expected here are enough 
in themselves to justify the use of formal methods, even if for lack of 
time (or other resources) no full formal development of the system is 
performed. 

b) Once we have a sufficient understanding of the problem to be specified, 
we must translate the informal requirements into a formal specifica- 
tion. This step will require us to provide interpretations for the unclear 
or missing parts of the informal requirements. Moreover, this formal- 
ization process will also be helpful to further detect inconsistencies 
and loose ends in the informal requirements. Here, a very important 
issue is to keep track of the interpretations made during the formaliza- 
tion process, in order to be able, later on, to take into account further 
modifications and changes of the informal requirements. 

c) When we have written the formal requirements specification, we must 
carefully check its adequacy with respect to the informal requirements: 
this part is called the validation of the formal specification. 

In principle there should be some interaction between the specification 
team and the team who has designed the informal requirements, in par- 
ticular to check whether the suggested interpretations of the detected 
loose ends are adequate. In the framework of this case study, however, 
such interactions were not possible, and we can only use our intuition to 
assess the soundness of the interpretations made during the writing of the 
formal specification. 

2. Once a validated requirements specification is obtained, we can proceed 
toward a program by a sequence of refinements. Here a crucial step is the 
choice of an architecture of the desired implementation, expressed by an 
architectural specification as explained in Chap. 8. Each refinement step 
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leads to proof obligations which allow the correctness of the performed 
refinement to be assessed. In a last step, a program is derived from the 
final design specification. 

Before starting to explain how to write a Casl requirements specification 
of the steam-boiler control system, let us make a few comments on this case 
study. First, note that, although in principle a hybrid system, the steam-boiler 
control system turns out to be merely a reactive system, not even a ‘hard real- 
time’ system (see e.g. the assumptions made in App. C.3). Moreover, even if 
the whole system, i.e., the control program and its physical environment is 
distributed, this is not the case, at least at the requirements level, for the 
steam-boiler control system. Casl turns out to be especially well-suited to 
capture the features of systems like the steam-boiler control system, where 
data and control are equally important (in particular, here data play a promi- 
nent role in failure detection) . The various constructs provided by Casl allow 
the specifications to be formulated straightforwardly and perspicuously - and 
significantly more concisely than in other algebraic specification languages. 

As a last remark we must make clear that for the sake of simplicity the 
initialization phase of the steam-boiler control system (see App. C.4.1) is 
not specified. However, it should be clear that it would be straightforward to 
extend our specification so as to take the initialization phase into account, 
following exactly the same methodology as for the rest of the case study. 

This chapter is organized as follows. In Sect. 13.2 we start by providing 
some elementary specifications that will be useful for the rest of the case 
study. In Sect. 13.3 we explain how we will proceed to derive the Casl re- 
quirements specification in a stepwise way. Then in Sect. 13.4 we detail the 
specification of the mode of operation of the steam-boiler control system. In 
Sect. 13.5 we specify the detection of the various equipment failures, and in 
Sect. 13.6 we explain how we can compute, at each cycle, some predicted val- 
ues for the messages to be received at the next cycle. In Sect. 13.9 we explain 
how our Casl requirements specification can be validated, and in Sect. 13.10 
we refine the Casl requirements specification in a sequence of architectural 
specifications that describe the intended architecture of the implementation 
of the steam-boiler control system. 



13.2 Getting Started 

As explained in App. C.3, in each cycle the steam-boiler control system collects 
the messages received, performs some analysis of the information contained 
in them, and then sends messages to the physical units. We will therefore 
start with the specification of some elementary datatypes, such as “messages 
received” and “messages sent” . To specify the messages sent and received, we 
follow App. C.5 and C.6. Note that some messages have parameters (e.g. pump 
number, pump state, pump controller state, mode of operation), and we must 
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therefore specify the corresponding datatypes as well. For the sake of clarity, 
we group together all similar messages (e.g. all “repaired” messages, all “fail- 
ure acknowledgement” messages) by introducing a suitable parameter “physi- 
cal unit”. A physical unit is either a pump, a pump controller, the water level 
measuring device or the steam output measuring device. Remember that we 
do not specify the physical units as such, since we do not specify the physical 
environment of the steam-boiler (we do not specify the steam-boiler either, 
we only specify the steam-boiler control system) . Hence the datatype “physi- 
cal unit” is just an elementary datatype that says that we have some pumps, 
some pump controllers, and the two measuring devices. 

Some messages have a value v as parameter. From the informal require- 
ments we can infer that these values are (approximations of) real numbers, 
but it is not necessary at this level to make any decision about the exact 
specification of these values. In our case study, we will therefore rely on a 
very abstract (loose) specification Value, introducing a sort Value together 
with some operations and predicates, which are left unspecified (we expect 
of course that these operations and predicates will have the intuitive inter- 
pretation suggested by their names). This means that we consider Value as 
being a general parameter of our specification.^ This point is discussed again 
in Sect. 13.10. Note also that we will abstract from measuring units (such as 
liter, liter/sec), since ensuring that these units are consistently used is a very 
minor aspect of this particular case study. ^ 

This first analysis leads to the following specifications: Value, Basics, 
Messages_Sent, and Messages_Received. 

from B ASIC /Numbers get Nat 

%display __half %LATEX _/.8 
%display __square %LATEX 



spec Value = 

%% At this level we don’t care about the exact specification of values. 
Nat 

then sorts Nat < Value 

ops Value x Valuer Value, assoc, comm, unitO; 

Value X Value — > Value; 

__ X : Value x Value — > Value, assoc, comm, unit 1 ; 



^ We leave Value as an implicit parameter of our specifications, rather than us- 
ing generic specifications taking Value as a parameter, since our specifications 
are not to be instantiated by argument specifications describing several kinds 
of values, but on the contrary should all refer to the same abstract datatype of 
values. 

® It is of course possible to take measuring units into account, following for instance 
the method described in [18]. Appropriate Casl libraries supporting measuring 
units are currently being developed. 
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—12, -3 : Value Value] 
min, max : Value x Value Value 
preds Value x Value 

end 



spec 



end 



Basics = 

free type 
free type 
free type 
free type 



free type 



PumpNumber ::= Pumpl \ Pump2 \ PumpS \ Pump4] 
PumpState ::= Open \ Closed] 

PumpControllerState ::= Flow \ NoFlow] 

PhysicalUnit ::= Pump(PumpNumber) 

I PumpController{PumpNumber) 

I SteamOutput \ WaterLevel] 

Mode ::= Initialization \ Normal \ Degraded 
I Rescue \ Emergency Stop] 



spec Messages_Sent = 

Basics 

then free type 

S.Message ::= MODE(Mode) \ PROGRAM .READY \ VALVE 
I OPEN .PUMP (PumpNumber) 

I CLOSE. PUMP (PumpNumber) 

I PAIL URE. DETECTION ( Physical Unit ) 

I REPAIRED .A CKNO WLED CEMENT (Physical Unit ) ; 

end 



spec MessageS-Received = 

Basics and Value 

then free type 

R.Message ::= STOP \ STEAM .BOILER.WAITING 
I PHYSICAL.UNITS. READY 

I PUMP .STATE(PumpNumber] PumpState) 

I P UMP . CONTR OLLER .ST A TE ( PumpNumber ; 

PumpControllerState) 

I LEVEL(Value) \ STEAM (Value) 

I REPAIRED (PhysicalUnit) 

I PAIL URE .A CKNO WLED CEMENT (Physical Unit) 

I junk] 

end 

In addition to the “messages received” specified in App. C.6, we add an 
extra constant message junk. This message will represent any message received 
which does not belong to the class of recognized messages. We do not add a 
similar message to the messages sent, since we may assume that the steam- 
boiler control system will only send proper messages. Obviously, receiving a 



160 13 Case Study: The Steam-Boiler Control System 



junk message will lead to the detection of a failure of the message transmission 
system. 

In the Sbcs_Constants specification we describe the various constants 
that characterize the steam-boiler (these constants are explained in App. C.2.6) 

spec Sbcs_Constants = 

Value 

then ops C, Ml, M2, Nl, N2, W, Ul, U2, P : Value; 

dt : Value %% Time duration between two cycles (5 sec.) 

%% These constants must verify some obvious properties: 

• 0 < Ml • Ml < Nl • Nl < N2 • N2 < M2 • M2 < C 

• 0<W •Ok Ul • 0 <U2 • 0 <P 

end 

We will also specify the datatypes “set of messages received” and “set 
of messages sent” since, as suggested at the end of App. C.3, all messages 
are supposed to be received (or emitted) simultaneously at each cycle. The 
two latter specifications are obtained by instantiation of a generic specifi- 
cation Set of “sets of elements”, which is imported from the library Ba- 
sic / StRUCTUREDD ATATYPES . 

from Basic/StructuredD ATATYPES get Set 
spec Preliminary = 

Set [MessageS-Received fit Elem i-^ R_Message] 
and Set [Messages_Sent fit Elem i-> S -Message] 
and Sbcs_Constants 

end 

As illustrated by the above specifications, it is particularly conve- 
nient to structure our formal specification into coherent, easy to grasp, 
named specifications that will be easily reused later on by referring to 
their names (and this of course will prove even more important in 
the sequel) . Moreover, free datatypes are especially useful here to ob- 
tain concise specifications. On the other hand, loose specifications are 
useful to avoid overspecification of values in Value and of the steam- 
boiler constants in Sbcs_Constants. Declaring that Nat is a subsort 
of Value ensures that natural numbers can be used as arguments of op- 
erations on values. Reusing standard specifications of usual datatypes 
from the Basic libraries avoids the need to specify them again, and 
of course it is essential that these specifications are generic in order 
to easily adapt them as desired when they are reused. Finally, display 
annotations are useful to conveniently display some symbols as usual 
mathematical symbols.^ 

^ In this chapter, metacomments about the adequacy of Casl features will be 
highlighted like this. 
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13.3 Carrying On 

As emphasized in App. C.3, the steam-boiler control system is a typical ex- 
ample of a control-command system. The specification of such systems always 
follows the same pattern: 

• A preliminary set of specifications group all the basic information about 
the system to be controlled, such as the specification of the various mes- 
sages to be exchanged between the system and its environment, and the 
specification of the various constants related to the system of interest. 
This is indeed the aim of the specification Preliminary introduced in 
the previous section. 

• Then, the various states of the control system should be described. At this 
stage, however, it would be much too early to determine which state vari- 
ables are needed. Thus states will be represented by values of a (loosely 
specified) sort State, equipped with some observers (corresponding to ac- 
cess to state variables). During the requirements analysis and formalization 
phase we may need further observers, to be introduced on a by-need basis. 

• Then a (group of) specification(s) will take care of the analysis of the 
messages received - here, of failure detection in particular. On the basis of 
this analysis, some actions should be taken, corresponding to the messages 
to be sent to the environment. State variables are also updated according 
to the result of the analysis of the messages received and to the messages 
to be sent. 

• Finally a specification describes the overall control-command system as a 
labeled transition system. 

A very rough preliminary sketch of the steam-boiler control system speci- 
fication looks therefore as follows: 

library Sbcs 

from B ASIC /Numbers get Nat 
from Basic/StructuredDatatypes get Set 
%display _Jialf %LATEX _j 2 
%display __square %LATEX 



spec Preliminary = %{ See previous section. }% 

spec Sbcs_State = 

Preliminary 
then sort State 

ops %% Needed state observers are introduced here. 

%% E.g., we need an observer for the mode of operation: 
mode : State —>■ Mode', 



end 
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spec Sbcs_Analysis = 

Sbcs_State 

then %% Analysis of messages received and in particular failure detection. 

%% Computation of the messages to be sent. 

op messages -to send : State x Set[R-Message] — > Set[S -Message]; 

%% Computation of the updates of the state variables. 

%{ For each observer obs defined in Sbcs_State, 

we introduce an operation next jobs that computes the 
corresponding update according to the analysis of the messages 
received in this round. For instance, we specify here an operation 
next-mode corresponding to the update of the observer mode. }% 
ops next-mode : State x Set[R-Message\ — > Mode; 

end 

spec SteamJ3oiler_Control_System = 

Sbcs_Analysis 
then op init : State 

pred is step : State x Set[R-Message] x Set[S -Message] x State 
%% Specihcation of the initial state init by means of the observers, e.g: 

• mode{init) = . . . 

• ... 

%{ Specihcation of isstep by means of the observers 
and of the updating operations, e.g.: }% 

Vs, s' : State; msgs : Set[R-Message]; Smsg : Set[S -Message] 

• isstep{s, msgs, Smsg, s') 

models') = nextjmode{s, msgs) A ... A 
Smsg = messages -to send{s, msgs) 
then %% Specihcation of the reachable states: 
free { pred reach : State 

Vs, s' : State; msgs : Set[R-Message]; Smsg : Set[S -Message] 

• reach{init) 

• reach{s) A is-step{s, msgs, Smsg, s') ^ reach(s') } 

end 

Of course the specification Sbcs_Analysis is likely to be further struc- 
tured into smaller pieces of specifications. Indeed, since the informal require- 
ments are too complex to be handled as a whole, we will therefore succes- 
sively concentrate on various parts of them. The study and formalization of 
each chunk of requirements will lead to specifications that will later on be put 
together to obtain the Sbcs_Analysis specification. As already pointed out, 
it is likely that when analyzing a chunk of requirements we will discover the 
need for new observers on states (i.e., new state variables). This means that 
the specification Sbcs_State will be subject to iterated extensions where we 
introduce the new observers that are needed. 
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For instance, in App. C.6 it is explained that when the STOP mes- 
sage has been received three times in a row, the program must go into the 
Emergency Stop mode. We need therefore an observer (i.e., a state variable) to 
record the number of times we have successively received the STOP message. 
So in the sequel we will start from the following specification of states: 

spec Sbcs_State_1 = 

Preliminary 
then sort State 

ops mode : State — > Mode] 

numSTOP : State — *■ Nat 

end 

Introducing the new observer numSTOP means that we will have to spec- 
ify a corresponding nextjnumSTOP operation in the Sbcs_Analysis specifi- 
cation. 

^ Let us insist again on the importance of structuring our formal 
specification into coherent, easy to grasp, named specifications that 
will be easy to reuse later on by referring to their names. As explained 
above it is moreover essential to rely on a loose specification of states 
so that we can introduce later on as many observers as needed. Using 
a predicate (such as isstep) to describe a labeled transition system is 
quite convenient here, and provides us with an elegant way of handling 
both input and output for each transition. Finally, it is essential to 
use a free constraint to specify the reachable states, and thus we need 
to combine parts with a loose interpretation and parts with an initial 
interpretation in the same specification. ^ 



13.4 Specifying the Mode of Operation 

Our next step is the specification of the various operating modes in which the 
steam-boiler control system operates. (As explained in Sect. 13.1 we do not 
take into account the Initialization mode in this specification.) According to 
App. C.4, the operating mode of the steam-boiler control system depends on 
which failures have been detected (see e.g. “all physical units [are] operating 
correctly”, “a failure of the water level measuring unit”, “detection of an 
erroneous transmission”). It depends also on the expected evolution of the 
water level (see “If the water level is risking to reach. . . ”). 

We will therefore assume that the specification Sbcs_Analysis will pro- 
vide the following predicates which, given a known state and newly received 
messages, should reflect the failures detected by the steam-boiler control sys- 
tem:^ 

® It is important to make a subtle distinction between the actual failures, about 
which we basically know nothiirg, and the failures detected by the steam-boiler 
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• Transmission _OK : State x Set[R-Message] 

should hold iff we rely on the message transmission system, 

• PU-OK : State x Set[R-Message] x PhysicalUnit 
should hold iff we rely on the corresponding physical unit, 

• Dangerous Water Level : State x Set[R-Message\ 

should hold iff we estimate that the water level risks reaching the min 
{Ml) or max {M2) limits. 

However, at this stage our understanding of the steam-boiler control system is 
still quite preliminary, and it is therefore too early to attempt to specify these 
predicates. Therefore, our specification Mode_Evolution, where we specify 
the new operating mode according to the previous one and the newly received 
messages (i.e., the operation next-mode), will be made generic w.r.t. these 
predicates. Let us emphasize that here genericity is used to ensure a loose 
coupling between the current specification of interest, Mode_Evolution, 
and other specifications expected to provide the needed predicates. 

Let us now explain how to specify the new mode of operation. At first 
glance the informal requirements (see App. C.4) look quite complicated, 
mainly because they explain, for each operating mode, under which condi- 
tions the steam-boiler control system should stay in the same operating mode 
or switch to another one. However, things get simpler if we analyze under 
which conditions the next mode is one of the specified operating modes. In 
particular, a careful analysis of the requirements shows that, except for switch- 
ing to the EmergencyStop mode, we can determine the new operating mode 
(after receiving some messages) without even taking into account the previous 
one. 

To improve the legibility of our specification it is better to introduce some 
auxiliary predicates {Everything -OK , AskedToStop, SystemStillControllable , 
and Emergency) that will facilitate the characterization of the conditions un- 
der which the system switches from one mode to another: 

• The aim of the predicate Everything-OK is to express that we believe that 
all physical units are operating correctly, including the message transmis- 
sion system. 

• The aim of the predicate AskedToStop is to determine if we have received 
the STOP message three times in a row. 

• The aim of the predicate SystemStillControllable is to characterize the con- 
ditions under which the steam-boiler control system will operate in Rescue 
mode. Let us point out that the corresponding part of the informal require- 
ments (see App. C.4. 4) is not totally clear, in particular the exact meaning 
of the sentence “if one can rely upon the information which comes from the 
units for controlling the pumps” . There is a double ambiguity here: on the 
one hand it is unclear whether “the pumps” means “all pumps” or “at least 



control system. The behavior of the steam-boiler control system is induced by the 
failures detected, whatever the actual failures are. 
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one pump”; on the other hand there are two ways of “controlling” each 
pump (the information sent by the pump and the information sent by the 
pump controller), and it is unclear whether “controlling” refers to both of 
them or only to the pump controller. Our interpretation will be as follows: 
we consider it is enough that at least one pump is “correctly working”, 
and for us correctly working will mean we rely on both the pump and the 
associated pump controller. As with all interpretations made during the 
formalization process, we should in principle interact with the designers of 
the informal requirements in order to clarify what was the exact intended 
meaning and to check that our interpretation is adequate. The important 
point is that our interpretation is entirely localized in the axiomatization 
of SystemStillControllable, and it will therefore be fairly easy to change 
our specification in case of misinterpretation. 

• The aim of the predicate Emergency is to characterize when we should 
switch to the EmergencyStop mode. In App. C.4.2, it is said that the 
steam-boiler control system should switch from Normal mode to Rescue 
mode as soon as a failure of the water level measuring unit is detected. 
However, in App. C.4.4, it is explained that the steam-boiler control system 
can only operate in Rescue mode if some additional conditions hold (rep- 
resented by our predicate SystemStillControllable). We decide therefore 
that when in Normal mode, if a failure of the water level measuring unit 
is detected, the steam-boiler control system will switch to Rescue mode 
only if SystemStillControllable holds, otherwise it will switch (directly) to 
EmergencyStop mode.® 

The axiomatization of the next mode of operation is now both simple and 

clear, as illustrated by the Mode_Evolution specification.^ 

spec Mode_Evolution 

[preds Transmission -OK : State x Set[R-Message]; 

PU-OK : State x Set[R-Message] x PhysicalUnit] 

Dangerous WaterLevel : State x Set[R-Message] ] 
given Sbcs_State_1 = 

local %% Auxiliary predicates to structure the specification of next-mode. 

® If our interpretation is incorrect, then in some cases we may have replaced 
a sequence Normal — > Rescue — > EmergencyStop by a sequence Normal — > 
EmergencyStop . Note that a sequence Normal — > Rescue — » Normal or Degraded 
is not possible since several cycles are necessary between a failure detection and 
the decision that the corresponding unit is again fully operational, see Sect. 13.5, 
i.e., we must have a sequence of the form Normal — > Rescue Rescue 

Normal or Degraded in such cases. 

^ Note that once in the EmergencyStop mode, we specify that we stay in this mode 
forever, rather than specifying that the steam-boiler control system actually stops. 
Note also that we realize that the operation next-numSTOP is better specified 
in this Mode_Evolution specification. 
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preds Everything _OK ^ AskedToStop, SystemStillControllable, 
Emergency : State x Set[R^Message] 

Vs : State; msgs : Set[R_Message] 

• Everything _OK{s, msgs) 

{Transmission-OK{s,msgs) A 

{\/pu : PhysicalUnit • PU -OK(s,msgs,pu))) 

• AskedToStop{s, msgs) <tA numSTOP(s) = 2 A STOP e msgs 

• SystemStiUControUable{s, msgs) 

{PU -OK{s, msgs, SteamOutput) A 

(3pn : PumpNumber • PU -OK (s,msgs, Pump(pn)) 

A PU -OK{s, msgs, PumpController{pn)))) 

• Emergency's, msgs) AA 

( models) = EmergencyStop V 
AskedToStop{s,msgs) V 
^ Transmission-OK {s , msgs) V 
DangerousWaterLevel{s,msgs) V 
PU-OK{s,msgs, WaterLevel) A 
^ SystemStillControllable{s , msgs)) ) 
within ops nextjmode : State x Set[R_Message] Mode; 

nextjnumSTOP : State x Set[R_Message] — > Nat 
Vs : State; msgs : Set[R-Message] 

%% Emergency stop mode: 

• Emergency's, msgs) next -mode{s, msgs) = EmergencyStop 
%% Normal mode: 

• Emergency {s, msgs) A 

Everything -OK {s , msgs) => next-mode{s , msgs) = Normal 
%% Degraded mode: 

• Emergency's, msgs) A 
Everything -OK {s , msgs) A 

PU-OK{s,msgs, WaterLevel) A 

Transmission-OK{s, msgs) next jmode{s, msgs) = Degraded 

%% Rescue mode: 

• Emergency {s, msgs) A 

^ PU-OK{s, msgs, WaterLevel) A 
SystemStillControllable{s , msgs) A 

Transmission -OK {s, msgs) next -mode{s, msgs) = Rescue 

%% next-numSTOP: 

• next-numSTOP{s,msgs) = numSTOP{s) + 1 when STOP e msgs 



In the next step of our formalization process, we will specify the predicates 
assumed by Mode_Evolution, which amounts to specifying the detection 
of equipment failures. This will be the topic of the next section. 
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^ Two essential features of Casl have been used in the specification 
Mode_Evolution. On the one hand, the use of a generic specification 
(with imports) ensures loose coupling of the current specification of 
interest with the rest of the steam-boiler control system specification. 

On the other hand, auxiliary predicates improve the legibility of the 
specification, and declaring them in the local part of the specification 
ensures they are hidden and therefore not exported. O 



13.5 Specifying the Detection of Eqnipment Failures 

The detection of equipment failures is described in App. C.7. It is quite clear 
that this detection is the most difficult part to formalize, mainly because 
both our intuition and the requirements (see e.g. “knows from elsewhere” , 
“incompatible with the dynamics”) suggest that we should take into account 
some inter-dependencies when detecting the various possible failures. 

For instance, if we ask a pump to stop, and if in the next cycle the pump 
state still indicates that the pump is open, we may in principle infer either 
a failure of the message transmission system (e.g. the stop order was not 
properly sent or was not received, or the message indicating the pump state 
has been corrupted) or a failure of the pump (which was not able to execute 
the stop order or which sends incorrect state messages). Our understanding 
of the requirements is that in such a case we must conclude there has been 
a failure of the pump, not of the message transmission system. Let us stress 
again that it is important to distinguish between the actual failures of the 
various pieces of equipment, and the diagnosis we will make. Only the latter 
is relevant in our specification. 

13.5.1 Understanding the Detection of Equipment Failures 

Before starting to specify the detection of equipment failures, we must proceed 
to a careful analysis of App. C.7, in order to clarify the inter-dependencies 
mentioned above. Only then will we be able to understand how to structure 
our specification of this crucial part of the problem. 

A first rough analysis of the part of App. C.7 devoted to the description of 
potential failures of the physical units (i.e. of the pumps, the pump controllers 
and the two measuring devices) shows that these failures are detected on 
the basis of the information contained in the messages received: we must 
check that the received values are in accordance with some expected values 
(according to the history of the system, i.e. according to the “dynamics of 
the system” and to the messages previously sent by the steam-boiler control 
system) . In particular, the detection of failures of the physical units relies on 
the fact that we have effectively received the necessary messages. If we have 
not received these messages, then we should conclude there has been a failure 
of the message transmission system (see below), and in these cases (see the 
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Mode_Evolution specification), the steam-boiler control system switches 
to the EmergencyStop mode. The further detection of failures of the physical 
units (in addition to the already detected failure of the message transmission 
system) is therefore irrelevant in such cases. 

Let us now consider the message transmission system. The description of 
potential failures of the message transmission system in App. C.7 is quite 
short. Basically, it tells us that we should check that the steam-boiler con- 
trol system has received all the messages it was expecting, and that none of 
the messages received is aberrant. However, it is important to note that the 
involved analysis of the messages received combines two aspects: on the one 
hand, there is some ‘static’ analysis of the messages received in order to check 
that all messages that must be present in each transmission are effectively 
present (see App. C.6). These messages are exactly the messages required to 
proceed to the detection of the failures of the physical units. On the other 
hand, the steam-boiler control system expects to receive (or, on the contrary, 
not to receive) some specific messages according to the history of the system 
(for instance, the steam-boiler control system expects to receive a “failure 
acknowledgement” from a physical unit once it has detected a corresponding 
failure and sent a “failure” message to this unit, but not before), and here some 
‘dynamic’ analysis is required. Obviously, the static analysis of the messages 
can be made on the basis of the messages received only, while the dynamic 
analysis must take into account, in addition to the messages received, the his- 
tory of the system, and more precisely the history of the failures detected so 
far and of the “failure acknowledgement” and “repaired” messages received 
so far. 

From this first analysis we draw the following conclusions on how to specify 
the detection of equipment failures: 

1. In a first step we should keep track of the failure status of the physical 
units. This will lead to a new observer status on states, and to a specifica- 
tion Status_Evolution of how this status evolves, i.e., of a next_status 
operation. 

2. Then we specify the detection of the message transmission system failures 
(hence Transmission _OK) in the specification Message_Transmission_ 
System_Failure. As explained above, in a first step we take care of the 
static analysis of the messages received, and then in a second step we take 
care of the dynamic analysis of the messages received, using how we have 
kept track of the “status” of the physical units, i.e., using the observer 
status. 

3. Then, for each physical unit, we specify the detection of its failures by 
comparing the message received with the expected one. For this compari- 
son we can freely assume that the static analysis of the messages received 
has been successful, i.e., that the message sent by the physical unit has 
been received. 

The corresponding specifications are described in the next subsections. 
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13.5.2 Keeping Track of the Status of the Physical Units 

Remember that to perform the dynamic analysis of the messages received, as 
explained above, we must check that we receive “failure acknowledgement” 
and “repaired” messages when appropriate. In order to do this, we must keep 
track of the failures detected and of the “failure acknowledgement” and “re- 
paired” messages received. Since the same reasoning applies for all physical 
units, we can do the analysis in a generic way. For each physical unit, we 
will keep track of its status, which can be either OK, FailureWithoutAck or 
Failure WithAck. The status of a physical unit will then be updated accord- 
ingly to the detection of failures, and receipt of “failure acknowledgement” 
and “repaired” messages. 

Thus, in a first step we should extend the specification Sbcs_State_ 1 to 
add an observer related to the failure status of physical units: 

spec Sbcs_State_2 = 

Sbcs_State_1 

then free type Status ::= OK \ FailureWithoutAck \ FailureWithAck 
op status : State x PhysicalUnit Status; 

end 

Now the specification of how the status of a physical unit evolves, i.e., 
of the operation next_status in Status_Evolution, is quite straightforward. 
We rely again on the predicate PU -OK A 

spec StatuS-Evolution 

[pred PU -OK : State x Set[R -Message] x PhysicalUnit] 
given Sbcs_State_2 = 

op next status : State x Set[R-Message] x PhysicalUnit — > Status 
Vs : State; msgs : Set[R-Message]; pu : PhysicalUnit 

• status{s,pu) = OK A PU-OK{s,msgs,pu) 

=> next status {s, msgs,pu) = OK 

• status(s, pu) = OK A ^ PU -OK{s, msgs, pu) 

=> nextstatus{s, msgs,pu) = FailureWithoutAck 

• status(s, pu) = FailureWithoutAck A 
FAILURE -ACKNOWLEDGEMENT {pu) e msgs 

=> nextstatus{s, msgs,pu) = Eailure WithAck 

• status{s , pu) = EailureWithoutAck A 

{EAILURE -ACKNOWLEDGEMENT {pu) e msgs) 

^ next status {s, msgs, pu) = EailureWithoutAck 

® The reader may detect that the specification Status_Evolution is not com- 
pletely correct. However, we prefer to give here the text of the specification as 
it was originally written, and we will explain in Sect. 13.9 how we detect, when 
validating the specification of the steam-boiler control system, that something is 
not correct, and how the problem can be fixed. 
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• statuses , pu) = Failure With Ack A REPAIRED(pu) e msgs 

=> next ^status {s, msgs,pu) = OK 

• statuses, pu) = Failure With Ack A {REPAIRED {pu) e msgs) 

=> next ^status {s, msgs,pu) = Failure With Ack 

end 

^ Here again we rely on a generic specification with imports to en- 
sure loose coupling. As claimed earlier, the loose specification of states 
makes it easy to introduce further observers (hence further state vari- 
ables). 

13.5.3 Detection of the Message Transmission System Failures 

As explained above, we first specify the static analysis of the messages re- 
ceived, and then we specify the dynamic analysis of these messages. 

To specify the static analysis of messages, it is necessary to check that all 
“indispensable” messages are present. In addition, a set of messages received 
is “acceptable” if there are no “duplicated” messages in this set. Since we have 
specified the collection of messages received as a set, we cannot have several 
occurrences of exactly the same message in this set. (Note that this means 
that our choice of using “sets” instead of “bags”, for instance, is therefore not 
totally innocent: either we assume that receiving several occurrences of exactly 
the same message will never happen, and this is an assumption about the 
environment, or we assume that this case should not lead to the detection of 
a failure of the message transmission system, and this is an assumption about 
the requirements.) However, specifying the collection of messages received as 
a set does not imply that a set of messages received cannot contain several 
LEVEL{v) messages, with distinct values (for instance). Hence we must check 
this explicitly. 

Remember that receiving “unknown” messages (i.e., messages that do not 
belong to the list of messages as specified in App. C.6) is taken into account via 
the extra constant junk message (see the specification Messages_Received). 
Another erroneous situation is when we simultaneously receive a failure ac- 
knowledgement and a repaired message for the same physical unit, i.e., that 
at least one cycle is needed between acknowledging the failure and repairing 
the unit. We will check this as well.® 

We focus now on the dynamic analysis of the messages received. As ex- 
plained above, to perform this dynamic analysis, we check that we receive 
“failure acknowledgement” and “repaired” messages when appropriate, ac- 
cording to the current status of each physical unit. We understand that for 

® We must confess that this belief is induced by our intuition about the behavior 
of the system. Indeed nothing in the requirements allows us to make either this 
interpretation or the opposite one. Although not essential, this assumption will 
simplify the axiomatization. 
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each failure signaled by the steam-boiler control system, the corresponding 
physical unit will send just one failure acknowledgement. Moreover, we will 
specify the steam-boiler control system in such a way that when it receives 
a “repaired” message, the steam-boiler control system acknowledges it imme- 
diately. Hence, if there is no problem with the message transmission system, 
and due to the fact that transmission time can be neglected, the steam-boiler 
control system must in principle receive only one repaired message for a given 
failure. Note that this does not contradict the “until. . . ” part of the sen- 
tences describing the “repaired” messages in the informal requirements (see 
App. C.6). To summarize, we consider that we have received an unexpected 
message when: 

• the program receives initialization messages but is no longer in initializa- 
tion mode; or 

• the program receives for some physical unit a “failure acknowledgement” 
without having previously sent the corresponding failure detection mes- 
sage, or receives redundant failure acknowledgements; or 

• the program receives for some physical unit a “repaired message” , but the 
unit is OK or its failure is not yet acknowledged. 

We now have all the ingredients required to specify the Transmission _OK 
predicate, taking into account both static and dynamic aspects, which leads 
to the following Message_Transmission_System_Failure specification. 

spec Message_Transmission_System_Failure = 

Sbcs_State_2 

then local %% Static analysis: 

pred .Js-static-OK : Set[R-Message] 

\/msgs : Set[R-Message] 

• msgs is-static-OK 
( -^{junk e msgs) A 
(3!w : Value • LEVEL{v) e msgs) A 
(3!ti : Value • STEAM {v) e msgs) A 
(\/pn : PumpNumber • 3!ps : PumpState • 

PUMP _STATE{pn,ps) e msgs) A 
(Vpn : PumpNumber • 3!pcs : PumpControllerState • 

PUMP. CONTROLLER.STATE{pn, pcs) e msgs) A 
(Vpit : PhysicalUnit • 

(EAILURE_ACKNOWLEDGEMENT{pu) e msgs 
A REPAIRED {pu) e msgs)) ) 

%% Dynamic analysis: 

pred ..is .N OT .dynamic. OK .for .. : Set\R.Message\ x State 
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Vs : State; msgs : Set[R_Message] 

• msgs is-NOT _dynamic-OK .for s 

( ( -^{mode{s) = Initialization) A 

( STEAM. BOILER.WAITING e msgs V 
PHYSIC AL.UNITS. READY e msgs ) ) 

V ( 3pu : PhysicalUnit • 

PAILURE.ACKNOWLEDGEMENT{pu) e msgs A 
{status {s , pu) = OK V status{s,pu) = PailureWithAck) ) 

V ( 3pu : PhysicalUnit • 

REPAIRED {pu) e msgs A 

{status {s , pu) = OK V status{s,pu) = Eailure Without Ack) )) 

within 

pred Transmission.OK : State x Set[R.Message] 

Vs : State; msgs : Set[R.Message] 

• Transmission.OK {s, msgs) 

{msgs is.static.OK A ~^{msgs is. NOT. dynamic. OK .for s)) 

end 

H Here again auxiliary predicates declared in the local part of the 
specification are quite useful to improve the legibility of the specifica- 
tion. Note also the use of nested quantifiers in axioms (‘V’, ‘3’ as well 
as ‘3!’) - without them the axioms would be much more intricate, or 
further auxiliary operations would be needed. ^ 



13.5.4 Detection of the Pump and Pump Controller Failures 

We start by considering the detection of the failures of the pumps. 

As explained in Sec 13.5.1, we rely on the predicted pump state message. 
Thus, in a first step we should extend the specification Sbcs_State_2 to 
add an observer related to the prediction of pump state messages. The pre- 
diction {Open or Closed) can however only be made when the status of the 
corresponding pump is OK. This is why we extend the sort PumpState to 
introduce a constant Unknown.PS: 



spec 

then 



end 



Sbcs_State_3 = 

Sbcs_State_2 

free type ExtendedPumpState ::= sort PumpState \ Unknown.PS 
op PS .predicted : State x PumpNumber —>■ ExtendedPumpState; 
%{ status{s, Pump{pn)) = OK 

{PS.predicted{s,pn) = Unknown.PS) }% 



The specification of the detection of pump failures is now straightforward 
and is given in the Pump_Failure specification. Remember that the meaning 
of Pump.OK is only relevant when Transmission.OK holds, which in partic- 
ular implies that for each pump, there is only one PUMP. STATE message for 
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it in msgs. Moreover, we check the received value only if the predicted value 
is not Unknown ^PS . 

spec Pump_Failure = 

Sbcs_State_3 

then pred Pump.OK : State x Set[R-Message] x PumpNumber 
Vs : State; msgs : Set[R_Message]; pn : PumpNumber 
• Pump^OK{s, msgs, pn) 

PS jpredicted{s,pn) = Unknown.PS V 

PUMP _STATE{pn, PS -predicted {s , pn) as PumpState) e msgs 

end 

Let us now consider the detection of the failures of the pump controllers. 
Again we rely on the predicted pump state controller message. Here, we must 
be a bit careful in order to reflect the fact that stopping a pump has an 
instantaneous effect, while starting it takes five seconds (see App. C.2.3). 
Since five seconds is, unfortunately, exactly the elapsed time between two 
cycles, when we decide to activate a pump we may have to wait two cycles to 
receive a corresponding Flow pump controller state. This is why, in addition 
to the constant Unknown_PCS , used for the cases where no prediction can be 
made since the pump controller is not working correctly, we also introduce a 
constant SoonFlow to be used for the prediction related to a just activated 
pump. 

spec Sbcs_State_4 = 

Sbcs_State_3 

then free type 

ExtendedPumpControllerState ::= sort PumpControllerState 

I SoonFlow I Unknown-PCS 
op PCS -predicted : State x PumpNumber 

— > ExtendedPumpControllerState; 

%{ status{s, PumpContr oiler (pn)) = OK 

(PCS-predicted(s,pn) = Unknown-PCS) }% 

end 

The specification of the detection of pump controller failures is now 
straightforward and is given in the Pump_Controller_Failure specifica- 
tion. Remember that the meaning of Pump -Controller -OK is only relevant 
when Transmission -OK holds, which in particular implies that for each pump, 
there is only one PUMP -CONTROLLER-STATE message for it in msgs. 
Moreover, we check the received value only if the predicted value is either 
Flow or NoFlow, since if it is SoonFlow or Unknown-PCS we cannot con- 
clude. 
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spec Pump_Controller_Failure = 

Sbcs_State_4 

then pred Pump_Controller_OK : State x Set[R_Message] x PumpNumber 
Vs : State; msgs : Set[R_Message]; pn : PumpNumber 
• Pump _Controller_OK{s, msgs, pn) 

PCS -predicted {s, pn) = Unknown-PCS 

V PCS -predicted{s , pn) = SoonFlow 

V PUMP-CONTROLLER.STATE{pn, 

PCS -predicted{s , pn) as Pump Controller State) e msgs 

end 

^ In the above specifications, using supersorts to extend previously 
defined datatypes is particularly convenient, and avoids the need to ex- 
plicitly relate values of PumpState and values of ExtendedPumpState 
(and similarly for PumpControllerState) . Note the use of explicit cast- 
ings in the axioms - in particular, the fact that predicates do not hold 
on undefined arguments resulting from castings is used in the above 
specifications. ^ 

13.5.5 Detection of the Steam and Water Level Measurement 
Device Failures 

To specify the failures of the steam and water level measurement devices, we 
must again rely on some predicted values. Here however we cannot predict 
an exact value, but only an interval in which the received value should be 
contained. This leads to the following extension of Sbcs_State_4: 

spec Sbcs_State_5 = 

Sbcs_State_4 

then free type Valpair ::= pair (low : Value; high : Value) 
ops steam -predicted, level -predicted : State —>■ Valpair; 

%{ low (steam 4 >redicted{s)) is the minimal steam output predicted, 
high(steam 4 >redicted(s)) is the maximal steam output predicted, 
and similarly for lev el -predicted. }% 

end 

The specification of the failures of the measurement devices is again 
straightforward and is given in the Steam_Failure and Level_Failure 
specifications. Remember that the meaning of Steam-OK (Level-OK resp.) is 
only relevant when Transmission -OK holds, which in particular implies that 
there is only one STEAM (v) (LEVEL(v) resp.) message in msgs (hence only 
one possible v in the quantifications Vv : Value ... below). Note also that 
here we assume that the predicted values will take care of the static limits ( 0 
and W for the steam, 0 and C for the water level), thus we do not need to 
check these static limits explicitly here. 
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spec Steam_Failure = 

Sbcs_State_5 

then pred Steam_OK : State x Set[R-Message] 

Vs : State; msgs : Set[R_Message] 

• Steam_OK{s,msgs) 

(Vu : Value • STEAM (v) e msgs 

{low {steam -predicted{s)) < v) A 
{v < high{steam_predicted{s))) ) 

end 

spec Level_Failure = 

Sbcs_State_5 

then pred LeveLOK : State x Set[R_Message] 

Vs : State; msgs : Set[R_Message] 

• LeveLOK {s, msgs) 4A 

{Vv : Value • LEVEL{v) e msgs 

{low {lev eLpr edict ed{s)) < v) A 
{v < high{leveLpredicted{s))) ) 

end 

13.5.6 Summing Up 

We now have all the ingredients necessary for the specification of the predi- 
cate PU-OK. This is done in the FailureJDetection specification, which 
integrates together all the specifications related to failure detection. 

spec FailureJDetection = 

{ Message_Transmission_System_Failure 

and Pump_Failure and Pump_Controller_Failure 
and Steam_Failure and Level_Failure 
then pred PU -OK : State x Set[R -Message] x PhysicalUnit 
Vs : State; msgs : Set[R-Message]; pn : PumpNumber 

• PU -OK{s, msgs, Pump{pn)) Pump -OK {s, msgs, pn) 

• PU -OK{s, msgs, PumpController{pn)) 

Pump -Controller -OK {s , msgs,pn) 

• PU -OK{s, msgs, SteamOutput) Steam-OK{s, msgs) 

• PU -OK{s, msgs, WaterLevel) LeveLOK {s, msgs) 

} hide ops Pump-OK , Pump -Controller -OK , Steam -OK , LeveLOK 
end 

^ In the above specification, we rely on explicit hiding of operations 
that are no longer needed. Moreover, the ‘same name, same thing’ 
principle is essential here: each of the five specifications extended in 
Failure_Detection is itself an extension of some specification Sbcs_ 
State_j of states, but with the ‘same name, same thing’ principle we 
get the effect that each of them extends Sbcs_State_5. S? 
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13.6 Predicting the Behavior of the Steam-Boiler 

In the previous section we have explained that failure detection was to a large 
extent based on a comparison between the messages received and the expected 
ones. For this purpose we have extended the specification Sbcs_State by sev- 
eral observers, which means we have assumed that at each cycle, we record in 
some state variables the information needed to compute the expected messages 
at the next cycle. According to our explanations in Sect. 13.3, we must now 
specify, for each observer obs introduced, a corresponding next.obs operation. 
This is the aim of this section. 

We have already defined the operation nextjmode in the generic specifica- 
tion Mode_Evolution (see Sect. 13.4) and the operation nextstatus in the 
generic specification Status_Evolution (see Sect. 13.5.2). Thus what is left 
is the specification of the operations next -PS -predicted, next -PCS -predicted, 
next steam -predicted and next -lev el -predicted. 

As explained in Sect. 13.5, the informal requirements suggest that we 
should take into account some inter-dependencies when predicting values to 
be received at the next cycle. For instance, the water level in the steam-boiler 
depends on how much steam is produced, but also on how much water is 
poured into the steam boiler by the pumps which are open. The information 
provided by the water level prediction is obviously crucial to decide whether 
we should activate or stop some pumps. On the other hand, to predict the 
pump state and pump controller state messages to be received at the next 
cycle, we must know which pumps have been ordered to be activated or to be 
stopped. 

From this first analysis we draw the following conclusions on how to specify 
the needed predictions: 

1. In a first step we should predict the interval in which the steam output is 
expected to stay during the next cycle: this prediction relies only on the 
just received value STEAM {v) (if we trust it) or on the previously pre- 
dicted values for the steam production. This is because the production of 
steam is expected to vary according to its maximum gradients of increase 
and decrease, and nothing else. 

2. In the next step we should decide whether some pumps have to be ordered 
to activate or to stop. This decision, plus the knowledge about the current 
state of the pumps (as much as we trust it), and the predicted evolution 
of the steam production, should allow us to predict the evolution of the 
water level. 

3. Then, on the basis of the current states of the pumps and pump controllers, 
together with the choice of pumps to be activated or stopped, we can 
predict the states of the pumps and of the pump controllers at the next 
cycle. 

Of course all these predictions are only meaningful as long as no failure of the 
message transmission system has been detected (but if this is not the case the 
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steam-boiler control system switches to the EmergencyStop mode and stops, 
so no predictions are needed anyway). The corresponding specifications are 
described in the next subsections. 

13.6.1 Predicting the Steam Output and the Water Level 

To predict the intervals in which the steam output and the water level are 
expected to stay during the next cycle, we will proceed as follows (taking into 
account the “Additional Information” provided in [1, pp. 507-509]): 

1. Following the analysis sketched above, when we are in the state s and 
have received the messages msgs, to predict the interval in which the 
steam output is expected to stay during the next cycle, we first should 
compute the adjusted ^steam interval: this interval is either the (inter- 
val reduced to the) received ^steam value if we can rely on it (i.e., if 
PU -OK{s,msgs, SteamOutput) holds), or the steam ^predicted interval 
(stored in the state s at the previous cycle). 

2. Then, we use the maximum gradients of increase and decrease (i.e., U1 
and U2), to predict the interval in which the steam output is expected to 
stay during the next cycle. 

3. We proceed similarly for the water level: first we compute the adjusted Jevel 
interval, which is either the (interval reduced to the) received Jevel value 
if we can rely on it (i.e., if PU-OK{s,msgs, WaterLevel) holds), or the 
level -predicted interval (stored in the state s at the previous cycle). 

4. Then we should consider hrokeu-pumps (the pumps pn for which either 
PU -OK{s,msgs, Pump{pn)) does not hold or PU -OK {s, msgs, Pump- 
Controller (pn)) does not hold - or both) and the reliable -pumps, which 
are not broken and are therefore known to be either Open or Closed. 

5. At this point we must decide which pumps are ordered to activate or to 
stop. 

However, the specific control strategy for deciding which pumps should he 
activated or stopped need not to be detailed in this requirements specifica- 
tion: this can be left to a further refinement towards an implementation of 
the steam-boiler control system. (Obviously the strategy should compare 
the adjusted -level with the recommended interval (N1,N2) and decide 
accordingly. ) 

We will therefore rely on a loosely specified chosen-pumps operation, for 
which we just impose some soundness conditions (e.g., a pump ordered to 
activate should be currently considered as “reliable” and Closed, a pump 
ordered to stop should be currently considered as “reliable” and Open). 

6. Now we can compute the minimal and maximal amounts of water that 
will be poured into the steam-boiler during the next cycle. To compute 
minimal -pumped -Water, we consider that only the pumps which are “re- 
liable” and already Open will pour some water in; the broken-pumps, the 
pumps which are just ordered to activate, and the pumps which are or- 
dered to stop are all considered not to be pouring water in. Similarly, to 
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compute maximal jpum'pedjwater, we consider that the pumps which are 
“reliable” and already Open, the pumps which are just ordered to acti- 
vate, as well as all the broken .pumps, may pour some water in; only the 
“reliable” pumps just ordered to stop or already stopped are known not 
to be pouring any water in. 

7. Finally, we can predict the interval in which the water level is expected 
to stay during the next cycle. 

8. This prediction is the basis for deciding whether the water level risks to 
reach a Dangerous WaterLevel (i.e., below Ml or above M2). 

Note that the intervals in which the steam output and the water level are 
expected to stay during the next cycle are predicted without considering the 
next.status of these devices. This is indeed necessary for the Degraded and 
Rescue operating modes. This leads to the following Steam_And_Level_ 
Prediction specification. 

spec Steam_And_Level_Prediction = 

FailureJDetection and Set [sort PumpNumber] 

then local 

ops received .steam : State x Set[R.Message] — > Value, 
adjusted .steam : State x Set[R.Message] — > Valpair] 
received. lev el : State x Set[R.Message] Value; 
adjusted. level : State x Set[R.Message] — > Valpair; 
broken. pumps : State x Set[R.Message] Set[PumpNumber]; 
reliable. pumps : 

State X Set[R.Message] x Pump State —>• Set[PumpNumber] 
Vs : State; msgs : Set[R.Message]; pn : PumpNumber; ps : PumpState 
%% Axioms for STEAM: 

• Transmission.OK(s, msgs) ^ 

STEAM {received. steam{s, msgs)) e msgs 

• adjusted.steam{s,msgs) = 

pair {received. steam{s, msgs), received. steam{s, msgs)) 

when {Transmission. OK {s, msgs) A PU .OK{s, msgs, SteamOutput)) 

else steam. predicted {s) 

%% Axioms for LEVEL: 

• Transmission.OK{s, msgs) ^ 

LEVEL{received.level{s, msgs)) e msgs 

• adjusted. level{s, msgs) = 

pair {received .level{s , msgs), received. level{s, msgs)) 

when {Transmission.OK{s,msgs) A PU .OK{s, msgs, WaterLevel)) 

else level. predicted{s) 

%% Axioms for auxiliary pumps operations: 

• pn e broken.pumps{s,msgs) 

^ ( PU .OK{s, msgs, Pump{pn)) A 

PU .OK{s, msgs, PumpController{pn)) ) 
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• pn e reliable-pumps{s, msgs, ps) 

{pn e broken jpumps{s,msgs)) A 
PUMP_STATE{pn, ps) e msgs 

within 

ops next steam ^predicted : State x Set[R_Message] — > Valpair] 
chosen_pumps : 

Statey<.Set[R-Message\y<.PumpState Set[PumpNumber\, 
minimal -pumped .water, maximal .pumped .water : 

State X Set[R-Message] — > Value] 
next .level .predicted : State x Set[R. Message] — > Valpair 
pred DangerousWaterLevel : State x Set[R.Message] 

%% Axioms for STEAM: 

Vs : State; msgs : Set[R.Message]; pn : PumpNumber 

• low{nextsteam_predicted{s,msgs)) = 

max{0 ,low{adjusted.steam{s,msgs)) — {U2 x dt)) 

• highinext steam. predicted{s, msgs)) = 

mini W, hiqhl adjusted steamls, msqs)) + (U1 X dt)) 

%% Axioms for PUMPS: 

• pn e ehosen.pumpslyS , msgs, Open) 

pn e reliable .pumps {s, msgs, Closed) 

• pn e chosen.pumps{s, msgs, Closed) 

pn e reliable .pumps {s, msgs, Open) 

• minimal .pumped. water {s, msgs) = 

dt X P X ]){reliable.pumps{s, msgs, Open) 

— cho s en. pump s{s, msgs. Closed)) 

• maximal. pumped. water {s, msgs) = 

dt X P X ’^{{reliable.pumps{s, msgs, Open) 

U chosen.pumpslyS , msgs. Open) 

U broken.pumps{s, msgs)) 

— cho s en. pump s{s, msgs. Closed)) 

%% Axioms for LEVEL: 

• low {next. level. predicted(s, msgs)) = 

max{0, {low {adjusted. level{s, msgs)) 

+ minimal. pumped. water {s, msgs)) 

- { {dt^ X Ul/2) 

+ {dt X high{adjusted.steam{s, msgs))) ) ) 

• high{next. level. predicted{s, msgs)) = 

min{C , {high{adjusted.level{s , msgs)) 

+ maximal. pumped. water {s, msqs)) 

- ( {dt^ X U2/2) 

+ {dt X low {adjusted. steam{s, msgs))) ) ) 

• DangerousWaterLevel{s,msgs) 

{low{next.level.predicted{s, msgs)) < Ml) V 
{M2 < high{next. level. predicted{s, msgs))) 
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hide ops minimal -pumped -water , maximal -pumped -water 

end 

^ Note the combination of implicit hiding of auxiliary operations de- 
clared in the local part and of explicit hiding: the operations minimal - 
pumped-water and maximal -pumped -water cannot be made local since 
their specification relies on chosen-pumps which must be exported, 

13.6.2 Predicting the Pump and Pump Controller States 

Specifying the predicted state of each pump at the next cycle is almost trivial. 
The next pump state is Unknown -PS if the next status of the pump is not 
OK, otherwise it should be Open if: 

• it is Open now and the pump is not ordered to stop, or 

• the pump is ordered to activate; 

otherwise, it should be Closed since: 

• it is Closed now and the pump is not ordered to activate, or 

• it is ordered to stop. 

This leads to the following Pump_State_Prediction specification. This 
specification extends Steam_And_Level_Prediction (since we rely on 
chosen-pumps for our predictions), and Status_Evolution (which provides 
next-status) instantiated by Failure_Detection (which provides the pred- 
icate PU-OK parameter of Status_Evolution). 

spec Pump_State_Prediction = 

Status-Evolution [ Failure_Detection ] 
and Steam_And_Level_Prediction 
then op next -PS -predicted : 

State X Set[R-Message] x PumpNumber —y ExtendedPump State 
Vs : State; msgs : Set[R-Message]; pn : PumpNumber 
• next -P S -predicted{s, msgs, pn) = 

Unknown-PS when —• {next status{s, msgs, Pump{pn)) = OK) 
else Open when ( PUMP STATE{pn, Open) e msgs A 

~^{pn e chosen-pumps{s, msgs, Closed)) ) 
y pn e chosen-pumps{s , msgs , Open) 

else Closed 

end 

The reasoning to predict the pump controller state is similar, but we must 
take into account that two cycles may be needed before a just activated pump 
leads to a Elow state (provided the pump is not stopped meanwhile). Thus, 
the next pump controller state is Unknown-PCS if the nextstatus of the 
pump controller is not OK , or if the nextstatus of the corresponding pump 
is not OK, otherwise the predicted pump controller state value is: 
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• Flow when the pump is not ordered to stop and it is currently Flow, or it 
is currently NoFlow but PCS -predicted SoonFlow; 

• NoFlow if the pump is ordered to stop, or if it is currently NoFlow and is 
not PCS -predicted SoonFlow and the pump is not ordered to activate; 

• SoonFlow otherwise. 

This leads to the following Pump_Controller_State_Prediction spec- 
ification. 

spec Pump_Controller_State_Prediction = 

StatuS-Evolution [ FailureJDetection ] 
and Steam_And_Level_Prediction 
then op next -PCS -predicted : 

State X Set[R -Message] x PumpNumber 

—> ExtendedPumpControllerState 
Vs : State; msgs : Set[R -Message]; pn : PumpNumber 
• next -P CS -predicted{s, msgs, pn) = 

Unknown-PCS when 

next statuses, msgs, PumpController(j)n)) = OK A 
next -status{s, msgs, Pump{pn)) = OK ) 
else Flow when 

( PUMP-CONTROLLER-STATE{pn, Elow) e msgs V 
( PUMP-CONTROLLER-STATE{pn, NoFlow) e msgs A 
PCS -predicted{s,pn) = SoonFlow ) ) 

A ^ {pn e chosen-pumps{s, msgs, Closed)) 
else NoFlow when 

{pn e chosen-pumps{s, msgs, Closed)) 

V ( PUMP-CONTROLLER-STATE{pn, NoFlow) e msgs A 
{PCS -predicted {s, pn) = SoonFlow) A 
~^{pn e chosen-pumps{s, msgs, Open)) ) 
else SoonFlow 

end 

All our predictions are summarized in the following PU_Prediction spec- 
ification. 

spec PU_Prediction = 

Pump_State_Prediction 
and Pump_Controller_State_Prediction 
%{ Both specifications extend Status_Evolution 
( instantiated by Failure_Detection) 
and Steam_And_Level_Prediction }% 

end 

^ Since the specification FailureJDetection provides the predi- 
cate PU -OK required by Status_Fvolution, we can now put pieces 
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together as illustrated by PU_Prediction. Again the ‘same name, 
same thing’ principle is essential here. ^ 



13.7 Specifying the Messages to Send 

At this stage we are left with the specification of the messages to send at each 
cycle. This is easily specified, following App. C.5, and leads to the following 
Sbcs_Analysis specification. 

The specification Sbcs_Analysis is obtained by instantiating the Mode_ 
Evolution specification by PU_Prediction, and extending the result by 
the specification of the operation messages -to send . 

spec Sbcs_Analysis = 

Mode_Evolution [PU_Prediction] 

then local 

ops PumpMessages, FailureDetectionMessages : 

State X Set[R-Message] Set\S -Message]] 

RepairedAcknowledgementMessages : 

Set[R-Message] — > Set[S -Message] 

Vs : State] msgs : Set[R-Message]] Smsg : S -Message 

• Smsg e PumpMessages{s,msgs) 

(3pn : PumpNumber • 

( pn e chosen -pumps{s , msgs , Open) 

A Smsg = OPEN -PUMP{pn) ) 

V { pn e chosen-pumps{s, msgs, Closed) 

A Smsg = CLOSE -PUMP{pn) ) ) 

• Smsg e EailureDetectionMessages{s,msgs) 

(3pit : PhysicalUnit • 

Smsg = FAILURE -DETECTION {pu) A 
next status {s, msgs, pu) = Eailure Without Ack ) 

• Smsg e RepairedAcknowledgementMessages{msgs) AA 

{3pu : PhysicalUnit • 

Smsg = REPAIRED -ACKNOWLEDCEMENT{pu) A 
next status {s, msgs, pu) = Eailure With Ack ) 

within 

op messages -to send : State x Set[R-Message] Set[S -Message] 

Vs : State] msgs : Set[R-Message] 

• messages -to send{s, msgs) = 

{PumpMessages {s, msgs) U 
PailureDetectionMessages{s , msgs) U 
RepairedAcknowledgementMessages{msgs)) 

+ MODE {next-mode{s, msgs)) 



end 
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^ We rely again here on auxiliary operations declared in the local part, 
and their axiomatization is fairly easy using existential quantifiers, 



13.8 The Steam-Boiler Control System Specification 

According to our work plan detailed in Sect. 13.3, we have already specified 
the main parts of our case study. First, let us display a basic (flat) specifica- 
tion equivalent to Sbcs_State_5 and where all the state observers are listed 
together. 

spec Sbcs_State = 

Preliminary 
then sort State 

free type Status ::= OK \ Failure WithoutAck \ Failure WithAck 
free type ExtendedPump State ::= sort Pump State \ Unknown.PS 

free type 

ExtendedPumpControllerState ::= sort Pump Controller State 

I SoonPlow I Unknown^PCS 
free type Valpair ::= pair (low : Value] high : Value) 
ops mode : State — > Mode; 

numSTOP : State Nat; 

status : State x PhysiealUnit Status; 

PS -predicted : State x PumpNumber 

—f ExtendedPump State; 

PCS -predicted : State x PumpNumber 

—> ExtendedPumpControllerState; 
steam -predicted, lev el -predicted : State — > Valpair 

end 

We are now ready to provide the specification of the steam-boiler control 
system, considered as a labeled transition system. We leave partly unspeci- 
fied the initial state init, since in our specification this state represents the 
state immediately following the receipt of the PFIYSICAL-UNITS -READY 
message. Hence intuitively the omitted axioms should take into account the 
messages sent and received during the initialization phase (at least at the end 
of it). It is therefore better to leave open for now the value of most observers 
on init, and to note that this would have to be taken care of when specifying 
the initialization phase. The value of mode(init) is specified according to the 
end of App. C.4.1. 

spec SteamJ3oiler_Control_System = 

Sbcs_Analysis 
then op init : State 

pred is step : State x Set[R-Message] x Set[S -Message] x State 
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%% Specification of the initial state init: 

• mode{init) = Normal V mode{init) = Degraded 
%% Specihcation of isstep-. 

Vs, s' : State; msgs : Set[R_Message]; Smsg : Set[S -Message] 

• is-step{s, msgs, Smsg, s') 

mode(s') = next jmode{s, msgs) A 
numSTOP{s') = next -numSTOP{s, msgs) A 
(Vpit : PhysicalUnit • 
status{s' , pu) = next status {s, msgs, pu)) A 
(Vpn : PumpNumber • 

PS -predicted {s' , pn) = next-PS -predicted{s, msgs, pn) A 
PCS -predicted{s' ,pn) = next -P CS -predieted{s, msgs, pn) ) A 
steam -predicted {s') = next steam-predicted{s, msgs) A 
level -predicted{s') = next -level -predicted{s, msgs) A 
Smsg = messages -to -send{s , msgs) 
then %% Specihcation of the reachable states: 
free { pred reach : State 

'is, s' : State; msgs : Set[R-Message]; Smsg : Set[S -Message] 

• reach{init) 

• reach{s) A is-step{s, msgs, Smsg, s') ^ reach{s') } 

end 



13.9 Validation of the Casl Requirements Specification 

Once the formalization of the informal requirements is completed, we must 
now face the following question: is our formal specification adequate? This 
is a difficult question to answer since there is no formal way to establish 
the adequacy of a formal specification w.r.t. informal requirements, i.e., we 
cannot prove this adequacy. However, we can try to test it, by performing 
various ‘experiments’. When these experiments are successful, our confidence 
in the formal specification is increased. If some experiment fails, then we 
can inspect the specification and try to understand the causes of the failure, 
possibly detecting some flaw in the specification. 

We will base our validation process on theorem proving, i.e., we will check 
that some formulas are logical consequences of our requirements specifica- 
tion Steam J3oiler_Control_System. For this purpose we use the tools 
described in Chap. 11. During this validation process we can consider two 
kinds of proof obligations: 

1. We can inspect the text of the specification and derive from this inspec- 
tion some formulas that are expected to be logical consequences of our 
specification. This can be considered as a kind of internal validation of 
the formal specification. 
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2. We can check that some expected properties inferred from the informal 
requirements are logical consequences of our specification (external valida- 
tion). To do this, we must first reanalyze the informal specification, state 
some expected properties, translate them into formulas, and then attempt 
to prove that these formulas are logical consequences of our specification. 
This task is not easy, since in general one has the feeling that all expected 
properties were already detected and included in the axioms during the 
formalization process. 

The application of these principles to the requirements specification of the 
steam-boiler control system leads to various proofs. Below we give only a few 
illustrative examples. 

For instance, let us consider the specification of next-mode in Mode_ 
Evolution: it is advisable to prove that all the cases considered in the spec- 
ification of next-mode are mutually exclusive, and that their disjunction is 
equivalent to true. This is a typical example of internal validation of the spec- 
ification, since we just consider the text of the specification to decide which 
proof attempt will be performed, without considering the informal require- 
ments again. We do not spell out the corresponding proofs here, but the 
reader can easily check that indeed the operation next-mode is well-defined 
(i.e., all cases are mutually exclusive and their disjunction is equivalent to 
true). In the same spirit we can prove that the same pump cannot simulta- 
neously be ordered to activate and to stop, that we never resignal a failure 
which has already been signaled, that as long as the operating mode is not 
set to EmergencyStop the water level is safe, etc. 

Let us now consider an example of external validation. According to our 
understanding of failure detection (see Sect. 13.5), if we have detected a failure 
of some physical unit pu (so PU -OK does not hold for pu), then the status of 
this physical unit should not be set to OK . The corresponding proof obligation 
reads as follows: 

SteamJ3oiler_Control_System 1= 

Vs : State; msgs : Set[R-Message]; pu : PhysiealUnit 
• Transmission-OK{s, msgs) A ^ PU -OK(s, msgs, pu) 

A reach{s) ^ {next status {s, msgs,pu) = OK) 

However here we are unable to discharge this proof obligation. A careful 
analysis of the proof attempt shows that the proof fails since it could be 
the case that, simultaneously with the receipt of a repaired message for the 
physical unit pu, we nevertheless detect again a failure of the same unit. From 
this analysis we conclude that the following axiom in Status_Evolution is 
not adequate: 

• status{s , pu) = Failure With Aek A REPAIRED{pu) is-in msgs 
=> next status {s, msgs,pu) = OK 

This means we must fix the Status_Evolution specification and replace 
the above axiom by: 
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• statuses , pu) = Failure With Ack A REPAIRED(pu) isjin msgs 
=> next ^status {s, msgs, pu) = OK when PU -OK{s,msgs,pu) 

else FailureWithoutAck 

Once the specification Status_Evolution is modified as explained above, 
we can prove that the expected property holds. 

To conclude, the reader should keep in mind that the validation of the 
specification is a very important task that deserves some serious attention. In 
this section we have only briefly illustrated some typical proof attempts that 
would naturally arise when validating the Steam_Boiler_Control_System 
specification, and obviously many other proof attempts are required to reach 
a stage where we can trust our requirements specification of the steam-boiler 
control system. 



13.10 Designing the Architectnre 

We now have a validated requirements specification Steam J3oiler_Control_ 
System of the steam-boiler control system. The next step is to refine it into 
an architectural specification, thereby prescribing the intended architecture 
of the implementation of the steam-boiler control system. Indeed, the expla- 
nations given in Sect. 13.3 suggest the following rather obvious architecture 
for the steam-boiler control system: 

arch spec Arch_Sbcs = 

units P : Value — > Preliminary; 

S : Preliminary ^ Sbcs_State; 

A : Sbcs_State ^ Sbcs_Analysis; 

C : Sbcs_Analysis ^ Steam_Boiler_Control_System 
result XV : Value • C [A [5 [P [ V]]]] 
end 

Note that we decide to describe the implementation of the steam-boiler 
control system as an open system, relying on an external component V im- 
plementing Value. This is consistent with our explanations in Sect. 13.2: 
choosing a specific implementation of Value is obviously orthogonal to de- 
signing the implementation of the steam-boiler control system. This means in 
particular that the component V implementing Value will encapsulate the 
chosen representation of natural numbers and values, together with operations 
and predicates operating on them. 

^ As illustrated by Arch_Sbcs, the intended architecture of the 
steam-boiler control system is easily described by an architectural 
specification. Then we can proceed with four separate implementa- 
tion tasks, which are independent of each other. ^ 
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In a next step, we can refine the specification Value ^ Preliminary of 
the component P into the following architectural specification. 

arch spec Arch_Preliminary = 



units SET 


{ sort Elem} x Nat ^ Set 


sort Elem]] 


B 


Basics; 




MS 


Messages_Sent given B; 




MR 


Value — > Messages_Received given B; 


CST 


Value ^ Sbcs_Constants 




result A V 


Value • SET [MS fit Elem ^ 


S -Message] [V] 



and SET [MR [ V] fit Elem ^ R.Message] [ V] 
and CST[V] 

end 

Here we decide to implement (generic) sets in a component SET, reused 
both for sets of messages received and sets of messages sent. Since the imple- 
mentation of natural numbers is provided by the (external) component V, we 
use V for the second argument of the generic component SET in the result 
unit term. 

^ Note how the generic specification with imports Set is transposed 
into a specification of a generic component SET. Note also, for the 
component MR, the use of a specification of a generic component ex- 
tending a given unit. 

The specification of the components C and S of Arch_Sbcs are simple 
enough that they do not need to be further architecturally refined. The speci- 
fication of the component S (which implements the states of the steam-boiler 
control system) can be refined into the following specification Unit_Sbcs_ 
State, which provides a concrete implementation of states as a record of all 
the observable values. 

from Basic/StructuredDatatypes get TotalMap 

spec Sbcs_State_Impl = 

Preliminary 

then free type Status ::= OK \ EailureWithoutAck \ Failure WithAck 

free type ExtendedPump State ::= sort PumpState \ Unknown.PS 
free type ExtendedPump Controllers tate ::= 

sort PumpControllerState \ SoonFlow \ Unknown_PCS 
free type Valpair ::= pair(low : Value] high : Value) 
then TotalMap [Basics fit S' PhysicalUnit] [sort Status] 
and TotalMap [Basics fit S i— > PumpNumber] [sort ExtendedPump State ] 
and TotalMap [Basics fit S i— > PumpNumber] 

[sort ExtendedPump Controllers tate ] 
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then free type State ::= mk_state{ 
mode : Mode] 
numSTOP : Nat] 

status : TotalMap[PhysicalUnit, Status]] 

PS ^predicted : 

TotalMap[PumpNumber , ExtendedPumpState ] ; 

PCS -predicted : 

TotalMap[PumpNumber , ExtendedPumpControllerState ] ; 
steam -predicted^ level -predicted : Valpair ) 
ops status{s : State] pu : PhysicalUnit) : Status 
= lookup {pu, status {s))] 

PS -predicted {s : State] pn : PumpNumber) : ExtendedPumpState 
= lookup {pn, PS -predicted{s))] 

PCS -predicted {s : State] pn : PumpNumber) 

: ExtendedPumpControllerState 
= lookup {pn, PCS -predicted {s)) 

end 

unit spec Unit_Sbcs_State = 

Preliminary — > Sbcs_State_Impl 



^ During the formalization process it was convenient to rely on a loose 
specification of states. At the design stage, this loose specification is 
refined into a specification where state variables are now explicit. ^ 

The specification Sbcs_State ^ Sbcs_Analysis of the component A of 
Arch_Sbcs can be refined into the following architectural specification: 

arch spec Arch_Analysis = 



units ED 
PR 
ME 
MTS 
result A S : 
end 



Sbcs_State — > Failure_Detection; 

Failure_Detection — > PU_Prediction; 
PU_Prediction ^ Mode_Evolution [PU_Prediction] 
Mode_Evolution [PU_Prediction] ^ Sbcs_Analysis 
Sbcs_State • MTS [ME [PR [ED [S]]]] 



In the above architectural specification Arch_Analysis, the component 
ED provides an implementation of failure detection, the component PR an 
implementation of the predicted state variables for the next cycle, the compo- 
nent ME provides an implementation of next-mode (and of next -numSTOP), 
and the component MTS provides an implementation of messages -to send . 

The specifications of the components ME and MTS are simple enough to 
be directly implemented. The specifications of the components ED and PR 
can be refined as follows. 
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arch spec Arch_Failure_Detection = 
units MTSF : Sbcs_State 

^ Message_Transmission_System_Failure; 



PF 


: Sbcs_State - 


Pump_Failure; 


POP 


: Sbcs_State - 


PuMP.CoNTROLLER F ailure; 


SF 


: Sbcs_State - 


Steam_Failure; 


LF 


: Sbcs_State - 


Level_Failure; 


PU 


: Message_Transmission_System_Failure 



X Pump_Failure X Pump_Controller_Failure 
X Steam_Failure X Level_Failure 
— > Failure_Detection 
result \S : Sbcs_State • 

PU [MTSF[S]] [PCF[S]] [^^[F]] 

hide Pump.OK , Pump.Controller _OK , Steam.OK , LeveLOK 

end 

The above architectural specification Arch_Failure_Detection refines 
the specification Sbcs_State ^ FailureJDetection of the component FD 
in Arch_Analysis and introduces a component for each kind of failure de- 
tection. Then the component PU implements PU -OK , and in the result unit 
expression we hide the auxiliary predicates provided by the components PF, 
POP, SF, and LF}° 

We refine the specification FailureJDetection ^ PU_Prediction of 
the component PR of the architectural specification Arch_Analysis as fol- 
lows: 

arch spec Arch_Prediction = 
units SE : Failure_Detection ^ 

Status-Evolution [ Failure_Detection ] ; 

SLP : Failure_Detection ^ Steam_And_Level_Prediction; 
PP : Status-Evolution [FailureJDetection] 

X Steam_And_Level_Prediction 
— > Pump_State_Prediction; 

POP : StatuS-Evolution [FailureJDetection] 

X Steam_And_Level_Prediction 

— > Pump_Controller_State_Prediction 
result XFD : FailureJDetection • 

local SEFD = SE [ED]; SLPED = SLP [FD] within 
PP [SEFD] [SLPFD] and POP [SEFD] [SLPFD] 

end 

These auxiliary predicates are already hidden in the specification Failure. 
Detection. However, remember that in the specification of a generic component, 
the target specification is always an implicit extension of the argument specifica- 
tions. This is why it is necessary to hide the auxiliary predicates at the level of 
the result unit expression. 
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In the above architectural specification, the component SE provides an im- 
plementation of next^status. The component SLP provides an implementation 
of next steam ^predicted , next Jevel -predicted, chosen-pumps, and Dangerous- 
WaterLevel. The component PP provides an implementation of next-PS -pred- 
icted, and the component PCP provides an implementation of next -PCS -pred- 
icted. 

We are now left with specifications of components that are simple enough 
to be directly implemented, and this concludes our case study. 



Appendices 




A 



Casl Quick Reference 



This appendix provides an overview of the (concrete) syntax of each part of 
Casl. 



Basic specifications 

• declarations, definitions: 

- sorts, subsorts 

- functions: total, partial 

- constants: total, partial 

- predicates 

- datatypes 

- sort generation constraints 

• variables, axioms 

- formulas 

- terms 

• symbols 

• comments 

• annotations 

Architectural specifications 

• named architectures, units 

• architectural specifications 

• unit specifications 

• unit declarations, definitions 

• unit expressions, terms 



Structured speeifications 

• specification structure 

- translation 

- hiding, revealing 

- union, extension 

- free extension, initiality 

- hiding local symbols 

- reference 

- instantiation 

• named, generic specifications 

- fitting arguments 

• named, generic views 

- fitting views 

• symbol lists, maps 

Libraries 

• named libraries 

• downloadings 

• library names, versions 



M. Bidoit and P.D. Mosses: CASL User Manual, LNCS 2900, pp. 193—201, 2004. 
(c) IFIP International Federation for Information Processing 2004 



194 A Casl Quick Reference 

A.l Basic Specifications 



sorts . . . 
ops . . . 
prods . . . 
types . . . 
generated { . . . } 
vars . . . 

V. . . . Fi... • Fr, 

• Fi ... • Fn 



list of items optional) 
sort declarations and definitions 
operation declarations and definitions 
predicate declarations and definitions 
datatype declarations and definitions 
sort generation constraint 
global variable declarations 
universally-quantified list of axioms 
unquantified list of axioms 



A. 1.1 Declarations and Definitions 
Sort Declarations and Definitions 



sort s 

sorts Si,. . . ,Sn 
sorts s < s' 
sorts Si , . . . , Sn < s' 
sorts s < Si ; . . . ; s < s„ 
sorts Si = . . . = Sn 
sort s = {n:s' • i^} 



sort declaration 

sorts declaration 

subsort declaration 

subsorts and supersort declaration 

subsort and supersorts declaration 

isomorphic sorts declaration 

subsort definition 



Function Declarations and Definitions 



op / : sj X • • • X > s 
op f : Si X ■■■ X Sn s 
op f : s X s —>■ s, assoc 

op f : s X s s' , comm 

op / : s X s s, idem 

op f : s X s —>■ s, unit T 

op f: sxs—S'S, ....... 

ops fi,...Jn: ... 

op f{vi ■. si; Vn : Sn) : s = T 

op f{vi ■. si; ...■ Vn : Sn) -.Ts = T 

op f{...ViJ,...,V^^■.Si...)... 

ops ; ... 



total function declaration 
partial function declaration 
associative binary function 
commutative binary function 
idempotent binary function 
unit term for binary function 
multiple function attributes 
functions declaration 
total function definition 
partial function definition 
abbreviated arguments 
multiple declarations/definitions 



Constant Declarations and Definitions 



op c : s 
op c :1s 

ops C 1 ^ . . . ^ Cn . S 

op c : s = T 
op c :1s = T 

ops ... ; ... 



constant declaration 
partial constant declaration 
constants declaration 
constant definition 
partial constant definition 
multiple declarations/definitions 
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Predicate Declarations and Definitions 



pred p : Si x ■ ■ ■ x Sn 

pred P-{) 

preds pi, . . . ,pn : . . . 

pred p{vi : si; . . . ; Vn ■ Sn) ^ F 

pred p ^ F 

pred p{...v^j,...,Vi^ : s* . 

preds . . . ; ... 

Datatype Declarations 

type s ::= A 
types si ::= Ai; 

Sfi An 

generated types . . . 
free types . . . 

Alternatives (A) 

f(s'i; ■■■; 4) 
f(4; 4 )? 

/(.../* :?s,...) 

■■ S^...) 

c 

sort s 

sorts s'j, ■ ■ ■ ,4 

Al I ... I Ajn 



predicate declaration 
constant predicate declaration 
predicates declaration 
predicate definition 
constant predicate definition 
abbreviated arguments 
multiple declarations/definitions 



datatype declaration with alternatives 
multi-sorted datatype declaration 

generated datatype declaration 
free datatype declaration 



total constructor function 

partial constructor function 

total constructor and selector functions 

total constructor, partial selector functions 

abbreviated selectors 

constant constructor value 

subsort 

subsorts 

multiple alternatives 



Sort Generation Constraints 



generated { sorts . . . 

ops . . . 
preds . . . 
types . . . 
} 



generated sorts 
generating operations 

generated sorts 

and generating constructors 
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A. 1.2 Variables and Axioms 
var V : s 

vars vi : Si ; . . . ; : s„ 

vars . . .vi, . . . ,Vn ■■ Sn ■ ■ ■ 
vars . . . ; ... 

Vu : s • Fi . . . • Fn 
V-yj , . . . , : s • ... 

V. . . ; . . . . ... 

• Fi ... • Fn 

Formulas (F) 

V... • F 

3... • F 
3!... • F 

Fi A... A Fn 
FiV ...V Fn 
F ^ F' 

F' if F 
F AAF' 

~^F 

true 

false 

p{Ti,..., Tn) 
to Ti ti . . . Tn tn 

q 

T = r 

rp p/ 

defT 
T e s 

Terms (T) 

f{Ti,...,Tn) 
to Ti ti ... Tn tn 
to Ti, . . . ,Tn ti 
C 
V 

T : s 
T as s 

T when F else T' 



global variable declaration 
global variables declaration 
abbreviated variables declaration 
multiple global variable declarations 
universally-quantified list of axioms 
abbreviated quantifications 
multiple quantifications 
unquantified list of axioms 



universal quantification on formula 

existential quantification 

unique-existential quantification 

conjunction 

disjunction 

implication 

reverse implication 

equivalence 

negation 

truth 

falsity 

predicate application 
mixfix predicate application 
constant predicate 
ordinary (strong) equality 
existential equality 
definedness 
subsort membership 



application 
mixfix application 
literal syntax 
constant 
variable 
sorted term 
projection to subsort 
conditional choice 
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A. 1.3 Symbols 

Character set: ASCII (with optional use of ISO Latin-I). 



Key Words and Signs 

Reserved key words (always lowercase): 

and arch as axiom axioms closed def else end exists false fit 
forall free from generated get given hide if in lambda library local 
not op ops pred preds result reveal sort sorts spec then to true 
type types unit units var vars version view when with within 

Reserved key signs: 

: :? = =><=> ^ .. | |_> y /\ 

Unreserved key signs: 

< * X -> ?![]{} 

Key words and signs representing mathematical symbols: 

forall exists existsl not in lambda =e= — > => <=> . • | — > /\ \/ 

V 3 3! ^ G A = — 

Identifiers 

Identifiers for sorts and variables are simple words (other than reserved words) 
possibly containing digits, primes, and single underscores: 

Elem Y Z2' A_Rather _Long ^Identifier 

Sort identifiers can also be compound: 

List[Inf\ Map[Index , Elem] 

Identifier for operations and predicates can moreover be sequences of (unre- 
served) signs, with any brackets [ ] { } balanced: 

+ -*/\& = <> []{}!?:.$©# 

or single decimal digits 1234-567890, or single quoted characters ' c' . 

The signs ( ) ; , ‘ % are not allowed in identifiers, nor are the ISO 

Latin-1 signs for general currency, yen, broken vertical bar, registered trade 
mark, masculine and feminine ordinals, left and right angle quotes, fractions, 
soft hyphen, acute accent, cedilla, macron, and umlaut. 

Operation and predicate identifiers can also be compound: 

order < __] 
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Function and predicate identifiers can also be infixes, prefixes, postfixes, 
and general mixfixes, formed from words and/or sequences of signs separated 
by double underscores (indicating the positions of the arguments), with any 
brackets [ ] { } balanced: 

||__|| {[— ]} push.^onto— selectl 

Invisible mixfix identifiers (such as ) with two or more arguments are 

allowed. (Subsort embeddings give the effect of invisible unary functions.) 

An operation, or predicate identifier can be compound, with a list of iden- 
tifiers appended to its final token. 

Literal Strings and Numbers 

''this is a string" J^2 3.14159 IE— 9 27.3e6 

Library Identifiers 

Names of libraries are either paths, e.g.: 

Basic/Numbers Basic/ AlgebraJI 

or URLs formed from A. . . Za. . . zO. . . 9$-_@.&+!*” ’(),~ and 
hexadecimal codes %xx, and prefixed by http:/ /, FTP:/ /, or file:/ / /. 
Version numbers of libraries are hierarchical: 0, 0.999, 1, 1.0, 1.0.2. 

A. 1.4 Comments 

%% This is a comment at the end of a line. . . 

. . . %{ This is an in-line comment }% . . . 

. . . %{ This a comment that might take 
several lines }% 

%[ This is for commenting-out text 

%{ including other kinds of comment }% ]% 

A. 1.5 Annotations 

A label is of the form %(text)%. 

An end-of-line annotation is of the general form %word . . . 
with a space following the word. 

A possibly multi-line annotation is of the general form %word( ... )% 
with no space preceding the ‘(’. 
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A. 2 Structured Specifications 



A. 2.1 Specifications (SP) 

SP with SM 
SP hide SL 
SP reveal SM 
SPi and . . . and SPn 
SPi then . . . then SPn 
free SP 

local SP within SP' 
closed SP 

SN 

SN[FAi]...[FAn] 



symbol translation 

hiding listed symbols 

revealing/translating listed symbols 

union 

extension 

free or initial 

hiding of local symbols 

self-contained 

reference to named specification 
instantiation of generic specification 



A. 2. 2 Named and Generic Specifications 



spec SN = SP end 

spec SN[SPi]. . . [5P„] = SP end 

spec SN [SPi ]. . . 

given SP';,. . . ,SP';^ = SP end 

Fitting Arguments {FA) 

SP fit SM 

SP 

FV 



named specification (end optional) 
generic specification (end optional) 
generic specification 
with imports (end optional) 



fitting by symbol map 
implicit fitting 
fitting view 



A. 2. 3 Named and Generic Views 



view VN : SP to SP' = SM end 
view VN [SPi]. . . [5P„] 

: SP to SP' = SM end 
view VN [SPi]. . . [SPn] 

given sp;,. . . ,SP';, 

: SP to SP' = SM end 



named view (end optional) 

generic view 

(end optional) 

generic view 

with imports 

(end optional) 



Fitting Views (FV) 
view VN 

view VN[FAi], . . [F4„] 



reference to named view 
instantiation of generic view 



A. 2. 4 Symbol Lists {SL) and Maps {SM) 

SYi,...,SYn 

SYi ^ SY',,...,SYn^ sy;^ 

...,SY,,... 



lists (maybe with sorts, ops, preds) 
maps (maybe with sorts, ops, preds) 
in a map, abbreviates . . . , SYi i— > SYi, . . . 
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A. 3 Architectural Specifications 



A. 3.1 Named Architectures and Units 

arch spec ASN = ASP end named arch. spec, (end optional) 

unit spec SN = USP end named unit spec, (end optional) 

A. 3. 2 Architectural Specifications (ASP) 

ASN arch. spec, name 

units UDj ; . . . ; UDn result UE basic arch. spec. 



A. 3. 3 Unit Specifications (USP) 



SP 

SPi X ...X SPn^ SP 
closed USP 
arch spec ASP 



unit specification 
generic-unit specification 
self-contained 
models of arch. spec. 



A. 3. 4 Unit Declarations and Definitions ( UD) 

UN : USP unit declaration 

UN : USP given UTx , , UT^ importing units 
UN = UE unit definition 



A. 3. 5 Unit Expressions {UE) 

UT 

XUNi :SPi; ...; UN„ : • UT 

A. 3. 6 Unit Terms (UT) 

UT with SM 

UT hide SL 

UT reveal SM 

UTi and . . . and t/T„ 

local UDi UDn within UT 

UN 

UN[UTi]...[UTn] 

UN[UTi Rt SMi]... [UTnRt SMn] 



unit term 
unit composition 



symbol translation 

hiding listed symbols 

revealing/translating listed symbols 

amalgamation 

local units 

unit name 

generic-unit application 
with fitting by symbol maps 
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A. 4 Libraries 



library LN . . . 



named library of downloadings, 
specifications, views 



A. 4.1 Downloadings 

from LN get IN i end downloads listed items 
from LN get . . . IN i— s- IN' . . . end renames downloaded items 



A. 4. 2 Library Names (LN) 



Basic/Numbers 

Basic/ Algebra JI version 0.999 

HTTP: //. . . 

HTTP://... version 1.0.^ 



greatest version registered 
specified version registered 
greatest version unregistered 
specified version unregistered 



B 

Points to Bear in Mind 



B.l Introduction 

• CoFI aims at establishing a wide consensus 4 

• The focus of CoFI is on algebraic techniques 5 

• CoFI has already achieved its main aims 5 

• CoFI is an open, voluntary initiative 6 

• CoFI has received funding as an ESPRIT Working Group, and is 

sponsored by IFIP WG 1.3 6 

• New participants are welcome! 7 

• Casl has been designed as a general-purpose algebraic specification 

language, subsuming many existing languages 7 

• Casl is at the center of a family of languages 8 

• Casl itself has several major parts 9 

B.2 Underlying Concepts 

• Casl is based on standard concepts of algebraic specification 11 

• A basic specification declares symbols, and gives axioms and 

constraints 11 

• The semantics of a basic specification is a signature and a class of 

models 12 

• Casl specifications may declare sorts, subsorts, operations, and 

predicates 12 

• Sorts are interpreted as carrier sets 12 

• Subsorts declarations are interpreted as embeddings 13 

• Operations may be declared as total or partial 13 

• Predicates are different from boolean-valued operations 13 

• Operation symbols and predicate symbols may be overloaded 14 

• Axioms are formulas of first-order logic 14 
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B Points to Bear in Mind 



• Sort generation constraints eliminate ‘junk’ from specific carrier sets. 15 

• The semantics of a structured specification is simply a signature 

and a class of models 16 

• A translation merely renames symbols 17 

• Hiding symbols removes parts of models 17 

• Union of specifications identifies common symbols 17 

• Extension of specifications identifies common symbols too 18 

• Free specifications restrict models to being free, with initiality as a 

special case 18 

• Generic specifications have parameters, and have to be instantiated 

when referenced 18 

• The semantics of an architectural specification reflects its modular 

structure 19 

• Architectural specifications involve the notions of persistent 

function and conservative extension 19 

• The semantics of a library of specifications is a mapping from the 

names of the specifications to their semantics 20 

B.3 Getting Started 

• Simple specifications may be written in Casl essentially as in many 

other algebraic specification languages 23 

• Casl provides also useful abbreviations 23 

• Casl allows loose, generated and free specifications 24 

• Casl syntax for declarations and axioms involves familiar notation, 

and is mostly self-explanatory 24 

• Specifications can easily be extended by new declarations and axioms. 25 

• In simple cases, an operation (or a predicate) symbol may be 
declared and its intended interpretation defined at the same time. ... 26 

• Symbols may be conveniently displayed as usual mathematical 

symbols by means of %display annotations 27 

• The %implies annotation is used to indicate that some axioms are 

supposedly redundant, being consequences of others 28 

• Attributes may be used to abbreviate axioms for associativity, 

commutativity, idempotence, and unit properties 29 

• Genericity of specifications can be made explicit using parameters. . . 29 

• References to generic specifications always instantiate the parameters. 30 

• Datatype declarations may be used to abbreviate declarations of 

sorts and constructors 32 

• Loose datatype declarations are appropriate when further 

constructors may be added in extensions 32 

• Sorts may be specified as generated by their constructors 33 

• Generated specifications are in general loose 34 

• Generated specifications need not be loose 35 
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• Generated types may need to be declared together 36 

• Free specifications provide initial semantics and avoid the need for 

explicit negation 36 

• Free datatype declarations are particularly convenient for defining 

enumerated datatypes 37 

• Free specifications can also be used when the constructors are 

related by some axioms 37 

• Predicates hold minimally in models of free specifications 38 

• Operations and predicates may be safely defined by induction on 

the constructors of a free datatype declaration 38 

• More care may be needed when defining operations or predicates 

on free datatypes when there are axioms relating the constructors. . . 39 

• Generic specifications often involve free extensions of (loose) 

parameters 40 

• Loose extensions of free specifications can avoid overspecification. ... 41 

• Datatypes with observer operations or predicates can be specified 

as generated instead of free 42 

• The %def annotation is useful to indicate that some operations or 

predicates are uniquely defined 43 

• Operations can be defined by axioms involving observer operations, 

instead of inductively on constructors 44 

• Sorts declared in free specifications are not necessarily generated 

by their constructors 44 

B.4 Partial Functions 

• Partial functions arise naturally 47 

• Partial functions are declared differently from total functions 47 

• Terms containing partial functions may be undefined, i.e., they may 

fail to denote any value 48 

• Functions, even total ones, propagate undefinedness 48 

• Predicates do not hold on undefined arguments 48 

• Equations hold when both terms are undefined 48 

• Special care is needed in specifications involving partial functions. ... 49 

• The definedness of a term can be checked or asserted 50 

• The domains of definition of partial functions can be specified exactly. 50 

• Loosely specified domains of definition may be useful 51 

• Domains of definition can be specified more or less explicitly. 51 

• Partial functions are minimally defined by default in free 

specifications 53 

• Selectors can be specified concisely in datatype declarations, and 

are usually partial 54 

• Selectors are usually total when there is only one constructor 54 

• Gonstructors may be partial 54 
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• Existential equality requires the definedness of both terms as well 

as their equality 55 

B.5 Subsorting 

• Subsorts and supersorts are often useful in Casl specifications 57 

• Subsort declarations directly express relationships between carrier 

sets 57 

• Operations declared on a sort are automatically inherited by its 

subsorts 58 

• Inheritance applies also for subsorts that are declared afterwards. ... 59 

• Subsort membership can be checked or asserted 59 

• Datatype declarations can involve subsort declarations 59 

• Subsorts may also arise as classifications of previously specified 

values, and their values can be explicitly defined 60 

• It may be useful to redeclare previously defined operations, using 

the new subsorts introduced 61 

• A subsort may correspond to the definition domain of a partial 

function 62 

• Using subsorts may avoid the need for partial functions 62 

• Casting a term from a supersort to a subsort is explicit and the 

value of the cast may be undefined 63 

• Supersorts may be useful when generalizing previously specified sorts. 64 

• Supersorts may also be used for extending the intended values by 

new values representing errors or exceptions 65 

B.6 Structuring Specifications 

• Large and complex specifications are easily built out of simpler ones 

by means of (a small number of) specification-building operations. . . 67 

• Union and extension can be used to structure specifications 67 

• Specifications may combine parts with loose, generated, and free 

interpretations 68 

• Renaming may be used to avoid unintended name clashes, or to 

adjust names of sorts and change notations for operations and 
predicates 69 

• When combining specifications, origins of symbols can be indicated. . 71 

• Auxiliary symbols used in structured specifications can be hidden. . . 71 

• Auxiliary symbols can be made local when they do not need to be 

exported 73 

• Care is needed with local sort declarations 74 

• Naming a specification allows its reuse 75 
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B.7 Generic Specifications 

• Making a specification generic (when appropriate) improves its 

reusability 77 

• Parameters are arbitrary specifications 78 

• The argument specification of an instantiation must provide 

symbols corresponding to those required by the parameter 78 

• The argument specification of an instantiation must ensure that the 

properties required by the parameter hold 79 

• There must be no shared symbols between the argument 
specification and the body of the instantiated generic specification. . . 80 

• In instantiations, the fitting of parameter symbols to identical 

argument symbols can be left implicit 80 

• The fitting of parameter sorts to unique argument sorts can also be 

left implicit 80 

• Fitting of operation and predicate symbols can sometimes be left 

implicit too, and can imply fitting of sorts 81 

• The intended fitting of the parameter symbols to the argument 

symbols may have to be specified explicitly 81 

• A generic specification may have more than one parameter 82 

• Instantiation of generic specifications with several parameters is 

similar to the case of just one parameter 82 

• Composition of generic specifications is expressed using instantiation. 84 

• Compound sorts introduced by a generic specification get 
automatically renamed on instantiation, which avoids name clashes. . 85 

• Compound symbols can also be used for operations and predicates. . . 87 

• Parameters should be distinguished from references to fixed 

specifications that are not intended to be instantiated 88 

• Argument specifications are always implicitly regarded as extension 

of the imports 89 

• Imports are also useful to prevent ill-formed instantiations 89 

• In generic specifications, auxiliary required specifications should be 

imported rather than extended 90 

• Views are named fitting maps, and can be defined along with 

specifications 90 

• Views can also be generic 91 

B.8 Specifying the Architecture of Implementations 

• Architectural specifications impose structure on implementations, 

whereas specification-building operations only structure the text of 
specifications 93 
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• An architectural specification consists of a list of unit declarations, 
specifying the required components, and a result part, indicating 

how they are to be combined 96 

• There can be several distinct architectural choices for the same 

requirements specification 97 

• Each unit declaration listed in an architectural specification 

corresponds to a separate implementation task 97 

• A unit can be implemented only if its specification is a conservative 

extension of the specifications of its given units 98 

• Genericity of components can be made explicit in architectural 

specifications 100 

• A generic component may be applied to an argument richer than 

required by its specification 101 

• Specifications of components can be named for further reuse 102 

• Both named and unnamed specifications can be used to specify 

components 102 

• Specifications of generic components should not be confused with 

generic specifications 103 

• A generic component may be applied more than once in the same 

architectural specification 103 

• Several applications of the same generic component is different from 
applications of several generic components with similar specifications. 104 

• Generic components may have more than one argument 105 

• Open systems can be described by architectural specifications using 

generic unit expressions in the result part 106 

• When components are to be combined, it is best to check that any 

shared symbol originates from the same non-generic component 107 

• Auxiliary unit definitions or local unit definitions may be used to 

avoid repetition of generic unit applications 109 

B.9 Libraries 

• Libraries are named collections of named specifications Ill 

• Local libraries are self-contained Ill 

• Distributed libraries support reuse Ill 

• Different versions of the same library are distinguished by 

hierarchical version numbers 112 

• Local libraries are self-contained collections of specifications 112 

• Specifications can refer to previous items in the same library 113 

• All kinds of named specifications can be included in libraries 114 

• Display, parsing, and literal syntax annotations apply to entire 

libraries 114 

• Libraries and library items can have author and date annotations. ... 116 

• Libraries can be installed on the Internet for remote access 116 
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• Validated libraries can be registered for public access 117 

• Libraries should include appropriate annotations 118 

• Libraries can include items downloaded from other libraries 118 

• Substantial libraries of basic datatypes are already available 119 

• Libraries need not be registered for public access 120 

• Subsequent versions of a library are distinguished by explicit 

version numbers 120 

• Libraries can refer to specific versions of other libraries 121 

• All downloadings should be collected at the beginning of a library. . . 122 

B.IO Foundations 

• A complete presentation of Casl is in the Reference Manual 125 

• Casl has a definitive summary. 125 

• Casl has a complete formal definition 126 

• Abstract and concrete syntax of Casl are defined formally 126 

• Casl has a complete formal semantics 126 

• Casl specifications denote classes of models 127 

• The semantics is largely institution-independent 127 

• The semantics is the ultimate reference for the meanings of all Casl 

constructs 128 

• Proof systems for various layers of Casl are provided 128 

• The foundations of our Casl are rock-solid! 129 

B.ll Tools 

• Casl specifications can be checked for well-formedness using a 

form-based web page 131 

• The Heterogeneous Tool Set (Hets) is the main analysis tool for 

Casl 132 

• Hets can be used for parsing and checking static well-formedness 

of specifications 133 

• Hets also displays and manages proof obligations, using 

development graphs 134 

• Nodes in a development graph correspond to Casl specifications. 

Arrows show how specifications are related by the structuring 
constructs 135 

• Internal nodes in a development graph correspond to unnamed 

parts of a structured specification 137 

• Hol-Casl is an interactive theorem prover for Casl, based on the 

tactical theorem prover Isabelle 138 

• Casl is linked to Isabelle/Hol by an encoding 138 

• Asf-|-Sdf was used to prototype the Casl syntax 139 
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• The Asf+Sdf Meta-Environment provides syntax-directed editing 

of Casl specifications 140 

B.12 Basic Libraries 

• The Casl Basic Libraries contain the standard datatypes 143 

• Hets can be used to get an overview of the Basic Libraries 143 



c 



The Steam-Boiler Control Specification 
Problem 



For completeness, the text describing the steam-boiler control system case 
study, as originally provided by Jean-Raymond Abrial, is reproduced here 
(except for the “Additional Information” section, see [1, pp. 507-509]). 



C.l Introduction 

This text constitutes an informal specification of a program which serves to 
control the level of water in a steam-boiler. It is important that the program 
works correctly because the quantity of water present when the steam-boiler 
is working has to be neither too low nor to high; otherwise the steam-boiler 
or the turbine sitting in front of it might be seriously affected. 

The proposed specification is derived from an original text that has been 
written by LtCol. J.C. Bauer for the Institute for Risk Research of the Uni- 
versity of Waterloo, Ontario, Canada. The original text has been submitted 
as a competition problem to be solved by the participants to the International 
Software Safety Symposium organized by the Institute for Risk Research. It 
has been given to us by the Institut de Protection et de Surete Nucleaire, 
Fontenay-aux-Roses, France. We would like to thank the author, the Institute 
for Risk Research, and the Institut de Protection et de Surete Nucleaire for 
their kind permission to use their text. 

The text to follow is severely biased to a particular implementation. This 
is very often the case with industrial specifications that are rarely indepen- 
dent from a certain implementation people have in mind. In that sense, this 
specification is realistic. Your first formal specification steps could be much 
more abstract if that seems important to you (in particular if your formalism 
allows you to do so). In other words, you are encouraged to structure your 
specification in a way that is not necessarily the same as the one proposed 
in what follows. But in any case, you are asked to demonstrate that your 
specification can be refined to an implementation that is close enough to the 
functional requirements of the “specification” proposed below. 



M. Bidoit and P.D. Mosses: CASL User Manual, LNCS 2900, pp. 211—219, 2004. 
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You might also judge that the specification contain some loose ends and 
inconsistencies. Do not hesitate to point them out and to take yourself some 
appropriate decisions. The idea, however, is that such inconsistencies should 
be solely within the organization of the system and not within its physical 
properties. 

We are aware of the fact that the text to follow does not propose any precise 
model of the physical evolution of the system, only elementary suggestions. 
As a consequence, you may have to take some simple, even simplistic, abstract 
decisions concerning such a physical model. 



C.2 Physical Environment 

The system comprises the following units: 

• the steam-boiler, 

• a device to measure the quantity of water in the steam-boiler, 

• four pumps to provide the steam-boiler with water, 

• four devices to supervise the pumps (one controller for each pump), 

• a device to measure the quantity of steam which comes out of the steam- 
boiler, 

• an operator desk, 

• a message transmission system. 

C.2.1 The Steam-Boiler 

The steam-boiler is characterized by the following elements: 

• A valve for evacuation of water. It serves only to empty the steam-boiler 
in its initial phase. 

• Its total capacity C (indicated in liters). 

• The minimal limit quantity Mj of water (in liters). Below Mj the steam- 
boiler would be in danger after five seconds, if the steam continued to come 
out at its maximum quantity without supply of water from the pumps. 

• The maximal limit quantity Mg of waters (in liters). Above Mg the steam- 
boiler would be in danger after five seconds, if the pumps continued to 
supply the steam-boiler with water without possibility to evacuate the 
steam. 

• The minimal normal quantity Aj of water in liters to be maintained in 
the steam-boiler during regular operation (Mj < Aj). 

• The maximal normal quantity Ag of water (in liters) to be maintained in 
the steam-boiler during regular operation (Ag < Mg). 

• The maximum quantity W of steam (in liters/sec) at the exit of the steam- 
boiler. 

• The maximum gradient Ui of increase of the quantity of steam (in 
liters/sec/sec). 
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• The maximum gradient U2 of decrease of the quantity of steam (in 
liters/sec/sec). 

C.2. 2 The Water Level Measurement Device 

The device to measure the level of water in the steam-boiler provides the 
following information: 

• the quantity q (in liters) of water in the steam-boiler. 

C.2. 3 The Pumps 

Each pump is characterized by the following elements: 

• Its capacity P (in liters/sec). 

• Its functioning mode: on or off. 

• It’s being started: after having been switched on, the pump needs five 
seconds to start pouring water into the boiler (this is due to the fact that 
the pump does not balance instantaneously the pressure of the steam- 
boiler) . 

• It’s being stopped: with instantaneous effect. 

C.2.4 The Pump Control Devices 

Each pump controller provides the following information: 

• the water circulates from the pump to the steam-boiler or, on the contrary, 
it does not circulate. 

C.2. 5 The Steam Measurement Device 

The device to measure the quantity of steam which comes out of the steam- 
boiler provides the following information: 

• a quantity of steam v (in liters/sec). 

C.2. 6 Summary of Constants and Variables 

The following table summarizes the various constants or physical variables of 
the system: 
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Unit 


Comment 




Quantity of water in the steam-boiler 


c 


liter 


Maximal capacity 


Ml 


liter 


Minimal limit 


M2 


liter 


Maximal limit 


Ni 


liter 


Minimal normal 


N2 


liter 


Maximal normal 




Outcome of steam at the exit of the steam-boiler 


W 


liter/sec 


Maximal quantity 


Ui 


liter/sec/sec 


Maximum gradient of increase 


U2 


liter/sec/sec 


Maximum gradient of decrease 




Capacity of each pump 


P 


liter/sec 


Nominal capacity 




Current measures 


q 


liter 


Quantity of water in the steam-boiler 


p 


liter/sec 


Throughput of the pumps 


V 


liter/sec 


Quantity of steam exiting the steam-boiler 



C.3 The Overall Operation of the Program 

The program communicates with the physical units through messages which 
are transmitted over a number of dedicated lines connecting each physical 
unit with the control unit. In first approximation, the time for transmission 
can be neglected. 

The program follows a cycle and a priori does not terminate. This cycle 
takes place each five seconds and consists of the following actions: 

• Reception of messages coming from the physical units. 

• Analysis of informations which have been received. 

• Transmission of messages to the physical units. 

To simplify matters, and in first approximation, all messages coming from (or 
going to) the physical units are supposed to be received (emitted) simultane- 
ously by the program at each cycle. 



C.4 Operation Modes of the Program 

The program operates in different modes, namely initialization, normal, de- 
graded, rescue, emergency stop. 
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C.4.1 Initialization Mode 

The initialization mode is the mode to start with. The program enters a state 
in which it waits for the message STEAM-BOILER_WAITING to come from 
the physical units. As soon as this message has been received the program 
checks whether the quantity of steam coming out of the steam-boiler is really 
zero. If the unit for detection of the level of steam is defective (that is, when v 
is not equal to zero), the program enters the emergency stop mode. If the quan- 
tity of water in the steam-boiler is above Ag the program activates the valve 
of the steam-boiler in order to empty it. If the quantity of water in the steam- 
boiler is below Aj then the program activates a pump to fill the steam-boiler. 
If the program realizes a failure of the water level detection unit it enters the 
emergency stop mode. As soon as a level of water between Aj and Ag has 
been reached the program send continuously the signal PROGRAMJIEADY 
to the physical units until it receives the signal PHYSIGAL_UNITS_READY 
which must necessarily be emitted by the physical units. As soon as this sig- 
nal has been received, the program enters either the mode normal if all the 
physical units operate correctly or the mode degraded if any physical unit is 
defective. A transmission failure puts the program into the mode emergency 
stop. 

C.4. 2 Normal Mode 

The normal mode is the standard operating mode in which the program tries 
to maintain the water level in the steam-boiler between Aj and Ag with all 
physical units operating correctly. As soon as the water level is below Aj or 
above Ag the level can be adjusted by the program by switching the pumps 
on or off. The corresponding decision is taken on the basis of the information 
which has been received from the physical units. As soon as the program 
recognizes a failure of the water level measuring unit it goes into rescue mode. 
Failure of any other physical unit puts the program into degraded mode. If 
the water level is risking to reach one of the limit values Mj or Mg the 
program enters the mode emergency stop. This risk is evaluated on the basis 
of a maximal behavior of the physical units. A transmission failure puts the 
program into emergency stop mode. 

C.4. 3 Degraded Mode 

The degraded mode is the mode in which the program tries to maintain a 
satisfactory water level despite of the presence of failure of some physical 
unit. It is assumed however that the water level measuring unit in the steam- 
boiler is working correctly. The functionality is the same as in the preceding 
case. Once all the units which were defective have been repaired, the program 
comes back to normal mode. As soon as the program sees that the water 
level measuring unit has a failure, the program goes into mode rescue. If the 
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water level is risking to reach one of the limit values Mj or M2 the program 
enters the mode emergency stop. A transmission failure puts the program into 
emergency stop mode. 

C.4.4 Rescue Mode 

The rescue mode is the mode in which the program tries to maintain a sat- 
isfactory water level despite of the failure of the water level measuring unit. 
The water level is then estimated by a computation which is done taking 
into account the maximum dynamics of the quantity of steam coming out 
of the steam-boiler. For the sake of simplicity, this calculation can suppose 
that exactly n liters of water, supplied by the pumps, do account for exactly 
the same amount of boiler contents (no thermal expansion) . This calculation 
can however be done only if the unit which measures the quantity of steam 
is itself working and if one can rely upon the information which comes from 
the units for controlling the pumps. As soon as the water measuring unit is 
repaired, the program returns into mode degraded or into mode normal. The 
program goes into emergency stop mode if it realizes that one of the following 
cases holds: the unit which measures the outcome of steam has a failure, or 
the units which control the pumps have a failure, or the water level risks to 
reach one of the two limit values. A transmission failure puts the program 
into emergency stop mode. 

C.4.5 Emergency Stop Mode 

The emergency stop mode is the mode into which the program has to go, as 
we have seen already, when either the vital units have a failure or when the 
water level risks to reach one of its two limit values. This mode can also be 
reached after detection of an erroneous transmission between the program and 
the physical units. This mode can also be set directly from outside. Once the 
program has reached the Emergency stop mode, the physical environment is 
then responsible to take appropriate actions, and the program stops. 



C.5 Messages Sent by the Program 

The following messages can be sent by the program: 

• MODE(?n): The program sends, at each cycle, its current mode of opera- 
tion to the physical units. 

• PROGRAMJIEADY: In initialization mode, as soon as the program as- 
sumes to be ready, this message is continuously sent until the message 
PHYSICAL_UNITS_READY coming from the physical units has been re- 
ceived. 
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• VALVE: In initialization mode this message is sent to the physical units 
to request opening and then closure of the valve for evacuation of water 
from the steam-boiler. 

• OPEN_PUMP(n): This message is sent to the physical units to activate a 
pump. 

• CLOSE_PUMP(n): This message is sent to the physical units to stop a 
pump. 

• PUMP_FAILUREJDETECTION(n): This message is sent (until receipt of 
the corresponding acknowledgement) to indicate to the physical units that 
the program has detected a pump failure. 

• PUMP.CONTROL FAILURE J3ETECTION(n) : This message is sent (un- 
til receipt of the corresponding acknowledgement) to indicate to the physi- 
cal units that the program has detected a failure of the physical unit which 
controls a pump. 

• LEVELJAILUREJDETECTION: This message is sent (until receipt of 
the corresponding acknowledgement) to indicate to the physical units that 
the program has detected a failure of the water level measuring unit. 

• STEAM_FAILURE_DETECTION: This message is sent (until receipt of 
the corresponding acknowledgement) to indicate to the physical units that 
the program has detected a failure of the physical unit which measures the 
outcome of steam. 

• PUMPJlEPAIRED^CKNOWLEDGEMENT(n): This message is sent 
by the program to acknowledge a message coming from the physical units 
and indicating that the corresponding pump has been repaired. 

• PUMP .CONTROL JlEPAIRED^CKNOWLEDGEMENT(n): This mes- 
sage is sent by the program to acknowledge a message coming from the 
physical units and indicating that the corresponding physical control unit 
has been repaired. 

• LEVELJIEPAIRED.ACKNOWLEDGEMENT: This message is sent by 
the program to acknowledge a message coming from the physical units 
and indicating that the water level measuring unit has been repaired. 

• STEAMJIEPAIREDMlCKNOWLEDGEMENT: This message is sent by 
the program to acknowledge a message coming from the physical units and 
indicating that the unit which measures the outcome of steam has been 
repaired. 

C.6 Messages Received by the Program 

The following messages can be received by the program: 

• STOP: When the message has been received three times in a row by the 
program, the program must go into emergency stop. 

• STEAMJ30ILER.WAITING: When this message is received in initializa- 
tion mode it triggers the effective start of the program. 
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• PHYSIC AL_UNITS_READY : This message when received in initialization 
mode acknowledges the message PROGRAMJIEADY which has been sent 
previously by the program. 

• PUMP_STATE(n, h): This message indicates the state of pump n (open 
or closed). This message must be present during each transmission. 

• PUMP_CONTROL_STATE(n, b) : This message gives the information which 
comes from the control unit of pump n (there is flow of water or there is 
no flow of water). This message must be present during each transmission. 

• LEVEL(w): This message contains the information which comes from the 
water level measuring unit. This message must be present during each 
transmission. 

• STEAM(ii): This message contains the information which comes from the 
unit which measures the outcome of steam. This message must be present 
during each transmission. 

• PUMP_REPAIRED(n): This message indicates that the corresponding 
pump has been repaired. It is sent by the physical units until a corre- 
sponding acknowledgement message has been sent by the program and 
received by the physical units. 

• PUMP_CONTROL_REPAIRED(n): This message indicates that the cor- 
responding control unit has been repaired. It is sent by the physical units 
until a corresponding acknowledgement message has been sent by the pro- 
gram and received by the physical units. 

• LEVEL .REPAIRED: This message indicates that the water level measur- 
ing unit has been repaired. It is sent by the physical units until a cor- 
responding acknowledgement message has been sent by the program and 
received by the physical units. 

• STEAM JLEPAIRED : This message indicates that the unit which mea- 
sures the outcome of steam has been repaired. It is sent by the physical 
units until a corresponding acknowledgement message has been sent by 
the program and received by the physical units. 

• PUMP JAILUREMiCKNOWLEDGEMENT(n) : By this message the phys- 
ical units acknowledge the receipt of the corresponding failure detection 
message which has been emitted previously by the program. 

• PUMP.GONTROL JAILURE.AGKNOWLEDGEMENT(n): By this mes- 
sage the physical units acknowledge the receipt of the corresponding failure 
detection message which has been emitted previously by the program. 

• LEVEL JAILURE.AGKNOWLEDGEMENT: By this message the phys- 
ical units acknowledge the receipt of the corresponding failure detection 
message which has been emitted previously by the program. 

• STEAMJAILUREMlGKNOWLEDGEMENT: By this message the phys- 
ical units acknowledge the receipt of the corresponding failure detection 
message which has been emitted previously by the program. 
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C.7 Detection of Equipment Failures 

The following erroneous kinds of behavior are distinguished to decide whether 

certain physical units have a failure: 

• PUMP: (1) Assume that the program has sent a start or stop message to 
a pump. The program detects that during the following transmission that 
pump does not indicate its having effectively been started or stopped. (2) 
The program detects that the pump changes its state spontaneously. 

• PUMP .CONTROLLER: (1) Assume that the program has sent a start 
or stop message to a pump. The program detects that during the second 
transmission after the start or stop message the pump does not indicate 
that the water is flowing or is not flowing; this despite of the fact that 
the program knows from elsewhere that the pump is working correctly. (2) 
The program detects that the unit changes its state spontaneously. 

• WATERJ.EVELA1EASURING.UNIT: (1) The program detects that the 
unit indicates a value which is out of the valid static limits (that is, between 
0 and C). (2) The program detects that the unit indicates a value which 
is incompatible with the dynamics of the system. 

• STEAMJ.EVELA1EASURING.UNIT: (1) The program detects that the 
unit indicates a value which is out of the valid static limits (that is, between 
0 and W). (2) The program detects that the unit indicates a value which 
is incompatible with the dynamics of the system. 

• TRANSMISSION: (1) The program receives a message whose presence is 
aberrant. (2) The program does not receive a message whose presence is 
indispensable. 
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